Part of lp.scripts.garbo View In Hierarchy
Known subclasses: lp.scripts.garbo.AnswerContactPruner, lp.scripts.garbo.BranchJobPruner, lp.scripts.garbo.BugNotificationPruner, lp.scripts.garbo.BugWatchActivityPruner, lp.scripts.garbo.CodeImportEventPruner, lp.scripts.garbo.CodeImportResultPruner, lp.scripts.garbo.DiffPruner, lp.scripts.garbo.GitJobPruner, lp.scripts.garbo.LiveFSFilePruner, lp.scripts.garbo.LoginTokenPruner, lp.scripts.garbo.ObsoleteBugAttachmentPruner, lp.scripts.garbo.POTranslationPruner, lp.scripts.garbo.PreviewDiffPruner, lp.scripts.garbo.SessionPruner, lp.scripts.garbo.SnapBuildJobPruner, lp.scripts.garbo.SnapFilePruner, lp.scripts.garbo.TeamMembershipPruner, lp.scripts.garbo.UnlinkedAccountPruner, lp.scripts.tests.test_garbo.BulkFooPruner
This is designed for the case where calculating the list of items is expensive, and this list may be huge. For this use case, it is impractical to calculate a batch of ids to remove each iteration.
One approach is using a temporary table, populating it with the set of items to remove at the start. However, this approach can perform badly as you either need to prune the temporary table as you go, or using OFFSET to skip to the next batch to remove which gets slower as we progress further through the list.
Instead, this implementation declares a CURSOR that can be used across multiple transactions, allowing us to calculate the set of items to remove just once and iterate over it, avoiding the seek-to-batch issues with a temporary table and OFFSET yet deleting batches of rows in separate transactions.
Method | getStore | The master Store for the table we are pruning. |
Method | __init__ | Undocumented |
Method | isDone | See ITunableLoop . |
Method | __call__ | See ITunableLoop . |
Method | cleanUp | See ITunableLoop . |
Inherited from TunableLoop:
Method | run | Undocumented |