Merge lp:~danilo/launchpad/migrate-current-flags into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Aaron Bentley on 2010-11-25 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 11982 |
| Proposed branch: | lp:~danilo/launchpad/migrate-current-flags |
| Merge into: | lp:launchpad |
| Diff against target: |
388 lines (+374/-0) 3 files modified
lib/lp/translations/scripts/migrate_current_flag.py (+161/-0) lib/lp/translations/scripts/tests/test_migrate_current_flag.py (+183/-0) scripts/rosetta/migrate_current_flag.py (+30/-0) |
| To merge this branch: | bzr merge lp:~danilo/launchpad/migrate-current-flags |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Aaron Bentley (community) | 2010-11-19 | Approve on 2010-11-25 | |
|
Review via email:
|
|||
Commit Message
Provide a script to set is_imported flag based on is_current flag for upstream projects.
Description of the Change
= Bug 677600 =
Provide a script to set is_imported flag for all TranslationMessages on
upstream projects in Launchpad where is_current is set. This is a
script to aid with transition to the new semantics for the data model
that we are doing in our integration branch
(lp:~launchpad/launchpad/recife).
== Implementation details ==
We are using a traditional tried-and-true migration framework through
DBLoopTuner. It warrants that we won't overload the DB replication.
There are no tests for the full script run simply because this is a
script that's going to be used only for the migration (basically twice:
once before the rollout, once after it).
== Tests ==
bin/test -cvvt getProductsWith
== Demo and Q/A ==
This will have to be Q/Ad on staging. Local runs are simple and
"update" two TranslationMessages total. Just do
scripts/
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
scripts/
./scripts/
8: '_pythonpath' imported but unused
| Данило Шеган (danilo) wrote : | # |
У пон, 22. 11 2010. у 15:21 +0000, Aaron Bentley пише:
> Review: Needs Fixing
> There appear to be multiple cases where this could do the wrong thing:
>
> <jtv> The code seems to assume that there can be only one is_imported TM per POTMsgSet.
> In which case, it's perfectly valid to say "I'm doing each TM once, and for each, I'll clear any previous is_imported flags first."
> But what of another TM for the same POTMsgSet and a different language, that's already been processed?
> It's had its flag set in a previous iteration, but now gets it callously cleared again "to make room" for a TM it doesn't even compete with. AFAICT there's a similar situation with divergence (which is the case where TM.potemplate is non-null).
Indeed, all well spotted. A few tests for the above and an
implementation that unsets only TMs that really are in the way.
Incremental diff attached.
| Aaron Bentley (abentley) wrote : | # |
Jtv was planning to address these issues.
"Данило Шеган" <email address hidden> wrote:
>У пон, 22. 11 2010. у 15:21 +0000, Aaron Bentley пише:
>> Review: Needs Fixing
>> There appear to be multiple cases where this could do the wrong
>thing:
>>
>> <jtv> The code seems to assume that there can be only one is_imported
>TM per POTMsgSet.
>> In which case, it's perfectly valid to say "I'm doing each TM once,
>and for each, I'll clear any previous is_imported flags first."
>> But what of another TM for the same POTMsgSet and a different
>language, that's already been processed?
>> It's had its flag set in a previous iteration, but now gets it
>callously cleared again "to make room" for a TM it doesn't even compete
>with. AFAICT there's a similar situation with divergence (which is the
>case where TM.potemplate is non-null).
>
>Indeed, all well spotted. A few tests for the above and an
>implementation that unsets only TMs that really are in the way.
>
>Incremental diff attached.
>
>
>--
>https:/
>You are reviewing the proposed merge of
>lp:~danilo/launchpad/migrate-current-flags into lp:launchpad/devel.
--
Sent from my phone. Please excuse my brevity.
| Jeroen T. Vermeulen (jtv) wrote : | # |
I actually started a branch based on this review, though I saved the important bit for when I was fresh in the morning. (Which is _naturally_ also when I lost power, a hard disk, and a router—why do I even bother with an expensive UPS?)
Anyway, my branch was lp:~jtv/launchpad/migrate-current-flags.
| Jeroen T. Vermeulen (jtv) wrote : | # |
Does this mean that Storm translates "X.potemplateID == Y.potemplateID" to "X.potemplate IS NOT DISTINCT FROM Y.potemplate" or something equivalent? I naïvely thought it would translate to "X.potemplate = Y.potemplate."
That's another gotcha with ORMs. Having to worry about where you're getting application-
| Данило Шеган (danilo) wrote : | # |
У уто, 23. 11 2010. у 07:57 +0000, Jeroen T. Vermeulen пише:
> Does this mean that Storm translates "X.potemplateID == Y.potemplateID"
> to "X.potemplate IS NOT DISTINCT FROM Y.potemplate" or something
> equivalent? I naïvely thought it would translate to "X.potemplate =
> Y.potemplate."
No, it translates it to what you expect. That's why the code is:
Existing test ("unsetting_
sharing (None) case, and a new diverged-test makes sure it works for the
mixed diverged-shared case.
A test case for diverged-diverged is missing, though I am pretty sure
that works. A test case for shared-diverged is also missing (i.e. shared
existing imported translation, diverged current translation).
> That's another gotcha with ORMs. Having to worry about where you're
> getting application-
> :/
It may come as a surprise, but I still do know a few things about ORMs
(and you may remember that it was me who found out about DISTINCT FROM
in the first place, exactly because we needed it so often :).
Jeroen, also, before I continued on this, I checked if you assigned the
card or the bug to yourself. You didn't so I fixed the branch in order
to help out (and it was very easy for me).
| Jeroen T. Vermeulen (jtv) wrote : | # |
OK, if it's still yours, please go ahead and land it. (I don't have workable EC2 right now).
| Данило Шеган (danilo) wrote : | # |
It'd be nice if there was a review statement to accompany that :)
| Jeroen T. Vermeulen (jtv) wrote : | # |
Ah, of course. We'll see if we can procure that.
| Aaron Bentley (abentley) wrote : | # |
jtv's branch has some of the changes that jtv made during my on-call review on IRC. Most of these comments would not apply if you had merged it.
"from storm.expr import And, Count, Or, Select" should be formatted as a multi-line import. It's also better to use storm.locals so you don't need multiple import statements:
from storm.expr import (
And,
Count,
Or,
Select,
)
Similarly:
from lp.translations
MigrateCurr
Should be:
from lp.translations
MigrateCurr
)
I also asked for a docstring for _updateTranslat
Also, the docstring for MigrateTranslat
None of these affect actual functionality, so I won't block landing, but I'd appreciate if you could fix them at some point.

There appear to be multiple cases where this could do the wrong thing:
<jtv> The code seems to assume that there can be only one is_imported TM per POTMsgSet.
In which case, it's perfectly valid to say "I'm doing each TM once, and for each, I'll clear any previous is_imported flags first."
But what of another TM for the same POTMsgSet and a different language, that's already been processed?
It's had its flag set in a previous iteration, but now gets it callously cleared again "to make room" for a TM it doesn't even compete with. AFAICT there's a similar situation with divergence (which is the case where TM.potemplate is non-null).