Unique violation on POFileTranslator while merging TranslationMessages
Bug #375978 reported by
Jeroen T. Vermeulen
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Данило Шеган |
Bug Description
The mv_pofiletransl
Full traceback: https:/
This most likely happens because we don't remove all relevant pofiletranslator records when removing a translationmessage (select into v_old_entry seems to fetch a set of ids, but it doesn't: we should fix this).
Changed in rosetta: | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in rosetta: | |
assignee: | nobody → Jeroen T. Vermeulen (jtv) |
milestone: | none → 2.2.5 |
status: | Triaged → In Progress |
description: | updated |
tags: | added: message-sharing |
Changed in rosetta: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
One thing that will go wrong is the deletion of the old POFileTranslator message. In the function, v_old_entry is the id of one POFileTranslator row referring to the TranslationMessage that's being changed. ("SELECT INTO" in the stored-procedure language uses the first result row and ignores the rest). But with message sharing there can be multiple POFileTranslator rows referring to that TranslationMessage.
A solution for that one would be to do only a "SELECT EXISTS" to check if there is a matching POFileTranslator row, and then make the DELETE match directly on latest_message = OLD.id instead of using an intermediate variable.