[okfn-help] vdm: strange behavior

Martijn Faassen faassen at startifact.com
Mon Aug 23 17:31:51 BST 2010


Hi there,

On Mon, Aug 23, 2010 at 4:01 PM, Martijn Faassen <faassen at startifact.com> wrote:
>> 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.

I've tried this with postgresql. Instead of a datetime column I just
create a float style column and pass time.time() as the default (this
is a float).

It works (the tests pass) if you create a column with a floating point
number with sufficient precision before and after the decimal
separator (postgresl likes to truncate aggressively if you don't).

Of course this would change the API in that suddenly
revision.timestamp is a float instead of a datetime, so this is no
good solution, but it may be a step in the right direction for
compatibility.

It might be that the exact table structure we create depends on the
database system in use; PostgreSQL could use DateTime and MySQL could
use a float. This might lead to hard to understand code however.
Alternatively we could translate the float column back to DateTime
objects on the fly, with a read-only property. But it would still make
direct queries of the revision table more difficult.

The alternative approach would be to also add an extra 'order' column
that automatically increments for each session created. This is
difficult to do in a database-independent manner though - MySQL for
instance doesn't support a Sequence construction so this needs to be
emulated. I also wonder whether we can actually guarantee that
revisions are always inserted into the database in temporal order.

If this guarantee can be made, introducing an autoincrement column
would be the simplest to gain compatibility between MySQL and
Postgresql. You mention though that adding uuids had a reason, is this
working out for you or are you really willing to switch back?

Regards,

Martijn



More information about the okfn-help mailing list