revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2025-03-10 11:24:49 +01:00
Code Issues Releases Wiki Activity
phorge-phorge/resources/sql/patches/102.heraldcleanup.php

9 lines
286 B
PHP
Raw Normal View History

Write fewer "applied" rows and clean up excess historical rows Summary: - Only write the <ruleID, phid> row if the rule is a one-time rule. - Delete all the rows for rules which aren't one-time. NOTE: This is probably like several million rows for Facebook and could take a while. Test Plan: Added some one-time and every-time rules, ran them against objects, verified only relevant rows were inserted. Ran upgrade script against a database with one-time and every-time "ruleapplied" rows, got the irrelevant rows removed. Reviewers: nh, btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1484
2012-01-25 11:53:39 -08:00
<?php
Remove a very old Herald garbage collection migration Summary: Ref T13048. This migration is from January 2012 and probably only impacted Facebook. It references `HeraldRepetitionPolicyConfig`, which I'd like to change significantly. I initially just replaced the constant with a literal `0`, but I don't think there's any actual value in retaining this migration nowadays. The cost of removing this migration is: if you installed Phabricator before January 2012 and haven't upgraded since then, you'll have a few more rows in the `APPLIED` table than necessary. Herald will still work correctly. Test Plan: Reading. Reviewers: amckinley Reviewed By: amckinley Maniphest Tasks: T13048 Differential Revision: https://secure.phabricator.com/D18924
2018-01-24 19:12:48 -08:00
// Once, this migration deleted some unnecessary rows written by Herald before
// January 2012. These rows don't hurt anything, they just cluttered up the
// database a bit.
Write fewer "applied" rows and clean up excess historical rows Summary: - Only write the <ruleID, phid> row if the rule is a one-time rule. - Delete all the rows for rules which aren't one-time. NOTE: This is probably like several million rows for Facebook and could take a while. Test Plan: Added some one-time and every-time rules, ran them against objects, verified only relevant rows were inserted. Ran upgrade script against a database with one-time and every-time "ruleapplied" rows, got the irrelevant rows removed. Reviewers: nh, btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1484
2012-01-25 11:53:39 -08:00
Remove a very old Herald garbage collection migration Summary: Ref T13048. This migration is from January 2012 and probably only impacted Facebook. It references `HeraldRepetitionPolicyConfig`, which I'd like to change significantly. I initially just replaced the constant with a literal `0`, but I don't think there's any actual value in retaining this migration nowadays. The cost of removing this migration is: if you installed Phabricator before January 2012 and haven't upgraded since then, you'll have a few more rows in the `APPLIED` table than necessary. Herald will still work correctly. Test Plan: Reading. Reviewers: amckinley Reviewed By: amckinley Maniphest Tasks: T13048 Differential Revision: https://secure.phabricator.com/D18924
2018-01-24 19:12:48 -08:00
// The migration was removed in January 2018 to make maintenance on rule
// repetition policies easier.
Copy permalink