[PATCH v2 8/9] parser: use Patch.objects.create instead of save()

Stephen Finucane stephen at that.guru
Sun Feb 25 23:25:52 AEDT 2018

On Sun, 2018-02-25 at 01:50 +1100, Daniel Axtens wrote:
> Attempts to do parallel parsing with MySQL threw the following errors:
> _mysql_exceptions.OperationalError: (1213, 'Deadlock found when trying to get lock; try restarting transaction')
> Looking at the code, it was thrown when we created a patch like this:
> patch = Patch(...)
> patch.save()
> The SQL statements that were being generated were weird:
> UPDATE "patchwork_patch" SET ...
> INSERT INTO "patchwork_patch" (...) VALUES (...)
> As far as I can tell, the update could never work, because it was
> trying to update a patch that didn't exist yet. My hypothesis is
> that Django somehow didn't quite 'get' that because of the backend
> complexity of the Patch model, so it tried to do an update, failed,
> and then tried an insert.
> Change the code to use Patch.objects.create, which makes the UPDATEs
> and the weird MySQL errors go away.
> Also move it up a bit earlier in the process so that if things go wrong
> later at least we've committed the patch to the db.
> Reviewed-by: Andrew Donnellan <andrew.donnellan at au1.ibm.com>
> Signed-off-by: Daniel Axtens <dja at axtens.net>

Yup, this makes total sense. The reason this was done this way
previously was that I wanted to ensure as much pre-work as possible was
done before saving patches. If that failed, the patch was "broken" and
shouldn't be saved. However, as we've seen, it's usually Patchwork, not
the patch, that's broken, and this pattern ensure the patch is never
saved. Changing the ordering here is therefore a sensible thing to do.
As such:

Reviewed-by: Stephen Finucane <stephen at that.guru>

More information about the Patchwork mailing list