revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-25 15:00:58 +01:00
Code Issues Releases Wiki Activity
phorge-phorge/resources/sql/patches/20130508.releephtransactionsmig.php

9 lines
290 B
PHP
Raw Normal View History

ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
<?php
Remove ReleephRequestEvent Summary: Ref T3663. This is obsolete code which is used only in this migration, which Facebook has already performed and which isn't relevant for any other installs. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3663 Differential Revision: https://secure.phabricator.com/D6777
2013-08-20 18:15:35 +02:00
// Previously, this migrated ReleephRequestEvents into ApplicationTransactions.
// Only Facebook ever generated meaningful ReleephRequestEvent data, and has
// already migrated, so this was cleaned up when ReleephRequestEvent was
// removed.
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
Remove ReleephRequestEvent Summary: Ref T3663. This is obsolete code which is used only in this migration, which Facebook has already performed and which isn't relevant for any other installs. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3663 Differential Revision: https://secure.phabricator.com/D6777
2013-08-20 18:15:35 +02:00
echo "(This migration is obsolete.)\n";
Copy permalink