Unique constraint violation in importer

[Jeroen T. Vermeulen]

The importer has been failing one file with this error:

2009-05-06 19:54:08 ERROR Got an unexpected exception while importing English (United Kingdom) (en_GB) translation of avogadro in Avogadro trunk
 -> http://launchpadlibrarian.net/26406514/zz6q7eI41bJTVGCqmBC5t3j4kpR.txt (duplicate key value violates unique constraint "tm__potmsgset__language__no_variant__shared__current__key"
)

Full traceback saved for posterity here: https://pastebin.canonical.com/17297/

This appears to be the failing file: https://pastebin.canonical.com/17296/

[Jeroen T. Vermeulen (jtv)]

What I don't understand is how this unique constraint could have triggered given that, in our current schema as I see it, this unique constraint includes variant even though variant is null.

[Jeroen T. Vermeulen (jtv)]

No, no, no, I misread. This is not one of the broken constraints of bug 373151. This is another one, without potemplate (so this one is for shared messages). The broken constraints are for diverged messages, so they include potemplate.

[Jeroen T. Vermeulen (jtv)]

After some joint bug-hunting with Danilo, the conclusion is that POTMsgSet.updateTranslation sets matching_message.potemplate after possibly setting is_current. That means that the is_current validator is run (and unsets a previously current message) against existing current messages for the _old_ potemplate value.

When we set is_imported afterwards, that validator tries to flush the intermediate state to the database in order to perform its check, and runs into the unique constraint.

The fix is to set matching_message.potemplate earlier. But we must still be careful when we do that: the pre-existing current/imported flags on the message could also cause this kind of conflict.

[Jeroen T. Vermeulen (jtv)]

Danilo and I have been looking into this.

[Данило Шеган (danilo)]

Fixed in devel 8430.

[Данило Шеган (danilo)]

Cherry-picked on Friday.