Merge lp:~stub/launchpad/garbo into lp:launchpad
Proposed by
Stuart Bishop
Status: | Merged | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Approved by: | Jeroen T. Vermeulen | ||||||||||||
Approved revision: | no longer in the source branch. | ||||||||||||
Merged at revision: | 12533 | ||||||||||||
Proposed branch: | lp:~stub/launchpad/garbo | ||||||||||||
Merge into: | lp:launchpad | ||||||||||||
Diff against target: |
477 lines (+304/-50) 7 files modified
database/schema/security.cfg (+2/-0) database/schema/trusted.sql (+22/-0) lib/canonical/launchpad/doc/looptuner.txt (+26/-0) lib/canonical/launchpad/interfaces/looptuner.py (+9/-0) lib/canonical/launchpad/utilities/looptuner.py (+54/-49) lib/lp/scripts/garbo.py (+108/-1) lib/lp/scripts/tests/test_garbo.py (+83/-0) |
||||||||||||
To merge this branch: | bzr merge lp:~stub/launchpad/garbo | ||||||||||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jeroen T. Vermeulen (community) | code | Approve | |
Review via email: mp+50595@code.launchpad.net |
Commit message
[r=jtv][bug=721195] Generic bulk deletion helper for garbo, and garbo job to remove garbage POTranslation rows
Description of the change
A generic bulk removal helper using the optimal method.
Garbage POTranslation record pruner, using the bulk removal garbo template.
Note that there are no tests for the POTranslationPruner - the behavior of the base class is already tested, and the only thing remaining is the SQL defining the rows to remove. It is pointless testing this, because we would need to use the same chunk of SQL in the test to calculate what rows should be matched. The pruner itself is invoked each time runDaily() is invoked in the existing tests.
To post a comment you must log in.
Thanks for implementing this cleanup. The disk space will be welcome! Daily runs may be a bit much, since it's so unusual for a POTranslation to become unreferenced. Any idea how long the query that searches for orphans will take?
Don't let the Needs Fixing vote put you off—most of the branch looks very good indeed. It's just that I feel the test needs some more work. I do have a few other notes, most in the form of questions because you probably know better than I do, actually.
It seems a bit of a shame to have a procedure just to wrap a FETCH. I think we're all on 8.4 now… have you tried putting the FETCH in a WITH instead? Also, is there no way to fetch n tuples at once?
The CLOSE ALL doesn't belong in BulkPruner.__init__ IMHO. Can't we have a cleanup method called in a "finally:"? If the client dies without passing through there, we wouldn't reuse the connection anyway and the cursor would quietly slip into oblivion.
As for the actual DELETE, doesn't it work with USING?
The reference to POComment is a gentle reminder that that table isn't actually in use. It's empty as well.
And then there's the test. It's a bit unwieldy and worse, relies on sample data. That's the part that needs fixing. It would be easier AFAICS to have two simple end-do-end tests: "create object plus BulkPruner that cleans it up; run; abort; show that the object is gone" and "create object plus BulkPruner that doesn't clean it up; run; show that the object is still there." For much of the rest you can trust LoopTuner test coverage. Batching behaviour would be best verified by a separate test method.
By the way, I suspect ZopelessDatabas eLayer would suffice for this test. Less setup.
Jeroen