[okfn-help] vdm: strange behavior

Mon Aug 23 15:01:50 BST 2010

Hi there,

On Sat, Aug 21, 2010 at 10:44 AM, Rufus Pollock <rufus.pollock at okfn.org> wrote:

> Great debugging Martijn! I'm surprised about this feature in MySQL --
> I thought most systems did at least microseconds.

Yeah, it's a pain. I remember running into it with Clio as well, while
writing tests, so I
was primed to this problem. With Clio I generated the datetime using
Python and in the
tests plugged into it artificially inflating the time so that they
would stretch longer, but that
wouldn't really work here.

What are you normally running on? PostgreSQL?

Of even with microsecond granularity you might still have a failure,
but only rarely (with
very fast machines).

> One way to resolve this would be to introduce a revision 'number'
> attribute which is an auto-incrementing integer. In fact up until v0.6
> revision id was an auto-incrementing number so you had this for free.
> However we switched to uuids to better support shares revisions
> between different repositories. However we could reintroduce this and
> it would resolve any ambiguity issues in the time stamps.

Alternatively for MySQL we can probably store the timestamp in some
other column type altogether.

This milisecond resolution issue has been an issue forever with MySQL
apparently.

Regards,

Martijn