Merge lp:~jtv/launchpad/bug-994650-scrub-pofiletranslator into lp:launchpad
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Jeroen T. Vermeulen on 2012-05-11 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merge reported by: | Jeroen T. Vermeulen | ||||
| Merged at revision: | not available | ||||
| Proposed branch: | lp:~jtv/launchpad/bug-994650-scrub-pofiletranslator | ||||
| Merge into: | lp:launchpad | ||||
| Diff against target: |
423 lines (+385/-0) 4 files modified
database/schema/security.cfg (+1/-0) lib/lp/scripts/garbo.py (+4/-0) lib/lp/translations/scripts/scrub_pofiletranslator.py (+161/-0) lib/lp/translations/scripts/tests/test_scrub_pofiletranslator.py (+219/-0) |
||||
| To merge this branch: | bzr merge lp:~jtv/launchpad/bug-994650-scrub-pofiletranslator | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Benji York (community) | code | 2012-05-07 | Approve on 2012-05-08 |
|
Review via email:
|
|||
Commit Message
POFileTranslator scrubber script.
Description of the Change
This is as discussed on the internal mailing list. In a series of branches that simplifies and streamlines POFileTranslator management, this is the only one that introduces new code. It won't run while we still have POFileTranslato
POFileTranslator is described as an “eager materialized view.” It's a cache of who contributed TranslationMessages to which POFiles, and when they last did.
What you see in this branch is a scrubbing script for POFileTranslator. Instead of trying (and in many ways failing) to maintain that table synchronously using a long and complex database trigger, Launchpad will keep it “eventually consistent” by running this script. The script doesn't care how data got where it is, so some painfully complex script code that updates the table can disappear. Instead, the script just finds out which entries are missing and which ones need adding, and does that.
The script may still need optimizing. I deliberately kept it simple. In the current code it would have been easy to check for and correct timestamps on the contributions as well, but I think that's of secondary importantance. Where we have a justified POFileTranslator record, its timestamp is likely to be correct; the known problems involve records being omitted altogether. And simplifications I'm introducing elsewhere may also cause records to be omitted, or left in place when they should be moved to different POFiles, or deleted.
| Jeroen T. Vermeulen (jtv) wrote : | # |
It's a good thing you spot these things. A few months on 2.7 and I'm forgetting that we still need 2.6.
The hard part of making measure_distance return an absolute value is coming up with a good name. I arrived at the verb “to size”: size_distance. Which also happens to be shorter.
| Jeroen T. Vermeulen (jtv) wrote : | # |
Late-breaking change: after a chat with StevenK, I turned this into a Garbo loop. See revisions 15215 and beyond.
Note that the “launchpad” database user does not have the privilege of deleting POFileTranslator records. I could just add that to facilitate testing, but it's going a bit far. Much as I hate the finicky SELECT restrictions of security.cfg, I do like the restricted write privileges for specialized tables.
| Benji York (benji) wrote : | # |
The changes look good to me. I can get behind fewer methods and more functions.

This branch looks good. Here are a couple of things I spotted
while reading over it.
I believe that this bit is a syntax error in Python 2.6 as dict nslator. py):
comprehensions were added in 2.7. (line 132 of the diff, from
scrub_pofiletra
return {poft.personID: poft for poft in pofts}
Converting it to something like this should work (untested):
return dict((poft. personID, poft) for poft in pofts)
Since you wrap all calls to measure_distance in abs, you could just put
the abs in measure_distance.