Fix update history checkin logic to not double save (#90)
Fix update history checkin logic to not double save (#90)

As far as I can understand this, the problem was that an
UpdateHistoryItem was created, and then immediately had `.save()`
called. Then, on postgres, it would then later do a bulk_create on the
UpdateHistoryItem model. Since the model instance had already been
saved, the bulk create was failing when it tried to create a second
(conjecture...), duplicate UpdateHistoryItem, due to the uniqueness
constraints.

This commit moves the `save()` into the non-postgres block, and allows
the bulk_create action on the model to insert the objects for Postgres.

My understanding is that the update_history needs to get saved
regardless, since the `pending_recorded` attribute gets set. This
doesn't seem to trigger a save because the ForeignKey relationship goes
the other way.

This solves the massive exception logging that occurs in my environment
as a result of this problem, leading to maxed out memory and CPU usage
on the server. Whether it correctly handles the data involved, I'm not
clear enough on how this works to say with 100% certainty that this is
all it needs.

erikng/sal,erikng/sal,salopensource/sal,sheagcraig/sal,salopensource/sal,sheagcraig/sal,salopensource/sal,erikng/sal,sheagcraig/sal,erikng/sal,sheagcraig/sal,salopensource/sal