As some of you may have noticed, the last batch of updates contained 209
updates with the ID of 'FEDORA-2008-10000'. This is is due to a flaw in the
way bodhi's PackageUpdate.assign_id() method finds the current update with the
highest id. Presently, it does a PackageUpdate.select(...,
orderBy=PackageUpdate.q.updateid). Since PackageUpdate.updateid is a unicode
column, and due to the fact that u'FEDORA-2008-10000' < u'FEDORA-2008-9999',
this started to fail miserably.

Attached is a patch that has the assign_id method order the query by the
date_pushed DateTimeCol in order to find the highest updateid. However, it
seems that SQLObject completely ignore milliseconds:

if datetime:
def DateTimeConverter(value, db):
return "'%04d-%02d-%02d %02d:%02d:%02d'" % (
value.year, value.month, value.day,
value.hour, value.minute,
value.second)

The problem with this is that we must now take into account multiple updates
that were pushed at the same second.

The "proper" way to fix this is at the model level, and probably to use an
integer for the updateid column. I'm in the process of finishing up the
SQLAlchemy port, which will properly solve this problem. In the mean time,
this hack will not require any database changes.

This patch also includes a test case for this 10k bug.

[lmacken@x300 bodhi]$ nosetests
bodhi/tests/test_model.py:TestPackageUpdate.test_id
.
----------------------------------------------------------------------
Ran 1 test in 0.084s

OK

Once approved and applied, I will push out a fixed package (to releng2 only),
fix the existing updates from the last push, and send out an errata containing
the new update IDs.

+1's ?

luke

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list