[okfn-help] vdm: strange behavior

[Rufus Pollock]

On 8 September 2010 14:20, Martijn Faassen <faassen at startifact.com> wrote:
> Hoi,
>
> On Wed, Sep 8, 2010 at 12:38 PM, Rufus Pollock <rufus.pollock at okfn.org> wrote:
>
>>> I'm not sure I'm not reading this out of order, but I've reported
>>> already a while ago that I created a special type for SQLAlchemy that
>>> stores a higher-precision datetime as a decimal.
>>
>> But won't this require migrations for all systems currently using VDM
>> in that you are changing the underlying type (i.e. from datetime to a
>> decimal).
>
> I'm proposing this is only used when MySQL is detected somehow, the
> existing systems should
> continue working with datetime.

Great.

>>> I think this is the right way to go, as at least at the developer
>>> level the behavior of that column will be the same as for postgresql,
>>> as long as the SQLAlchemy APIs are used.
>>
>> OK, so there is no change to postgres column type involved here?
>> That's great news!
>
> Well, it should be transparent as long as we figure out how to create
> a different underlying table
> when MySQL is used - we need to use the decimal-backed column type in
> that case. So for any
> database except MySQL we'd use the normal SQLAlchemy datetime type,
> and in MySQL we'd
> use the special type I created. But these should behave in the same
> way to anyone doing queries through MySQL, as in the Python world
> they'll work with datetime objects.

I imagine a simple if statement in the relevant vdm module might be
enough here. The alternative is to write a custom-sqlalchemy type that
encapsulates this 'if' stuff (i.e. it is a datetime for sqlalchemy and
whatever different thing is needed for mysql).

I can guarantee that if you code this (with appropriate tests) this
will be pulled directly into the vdm main branch.

Rufus

> Regards,
>
> Martijn
>



-- 
Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/