Bodhi hash collision?
lmacken at redhat.com
Fri Feb 26 16:47:51 UTC 2010
On Sun, Feb 21, 2010 at 09:29:51PM -0500, Jon Masters wrote:
> On Sun, 2010-02-21 at 15:36 -0500, Luke Macken wrote:
> > On Fri, Feb 19, 2010 at 11:40:42PM -0500, Tom Lane wrote:
> > > Luke Macken <lmacken at redhat.com> writes:
> > > > A large number of updates currently suffer from duplicate IDs, and I
> > > > need to figure out a clever way to fix it.
> > >
> > > Would it be prudent to not push new updates until you've fixed it?
> > The duplicate update ID issue should be fixed, and the code I wrote to
> > fix it is in bodhi/tools/fix_dupe_ids.py
> OOI, what happened?
I described the issue earlier on in this thread, but basically...
Bodhi's PackageUpdate.assign_id method is a little crazy, mainly to hack
around SQLObject shortcomings (like not storing miliseconds in
datetime columns). This method apparently relied on the
PackageUpdate.date_pushed field *not* getting updated when an update
goes from testing->stable in order to determine the last ID assigned,
since we assign update ID's right when updates hit testing (which I am
thinking about changing in the next major release). I recently made a
subtle change that updates this date_pushed timestamp when a testing
update hits stable, and thus broke the id assignment algorithm. Sadly,
the test suite did not initially catch this issue, but I have since
added a test to reproduce the issue, and have written code to detect
these duplicates and re-assign their IDs.
More information about the devel