On 7 September 2010 19:56, Martijn Faassen <[email protected]> wrote: > Hi there, > > On Tue, Sep 7, 2010 at 7:56 PM, Rufus Pollock <[email protected]> wrote: >>> 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. >> >> You could implement this at a lower level in sqlalchemy, i.e. by >> creating a custom type. In many ways if we are going to support mysql >> (despite it's poor timestamp behaviour) I would like to special case >> it where possible and not disturb the existing db structure (for >> psql/sqlite etc) -- even if this is a bit ugly! > > 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 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! Rufus > Regards, > > Martijn > -- Open Knowledge Foundation Promoting Open Knowledge in a Digital Age http://www.okfn.org/ - http://blog.okfn.org/ _______________________________________________ okfn-help mailing list [email protected] http://lists.okfn.org/mailman/listinfo/okfn-help
