[PEAK] DateTime, and datatype methods

[Phillip J. Eby]

At 06:05 PM 10/26/04 -0400, R. David Murray wrote:
>I copied the DateTime class from Bulletin.
>
>I have mxDateTime installed on my system, but am not referencing
>it in my code.
>
>I'm using sqlite for my DM backends.
>
>When I look at my DateTIme values retrieved from a DM, they are mx
>DateTime objects.  What am I doing wrong?  Is sqlite automatically
>using mx DateTime or something?

It must be, because 'grep -r mx peak' turns up no hits.


>   If so, why doesn't the code in
>mdl_normalize fix it?

Probably because mdl_normalize is only called when you assign values to 
attributes at the API level.

Remember: when you write a DM, you're supposed to deal with the object's 
internal state, and hand it properly-prepared values, or the absence 
thereof.  DM's don't get the advantage of API conveniences.


>I stuck a "print type(value)" into the mdl_normalize, but it prints
>out either 'str' or 'datetime.datetime'.  Yet when I do a type on
>a retrieved value I get 'DateTime', and the method list (from a
>'dir') looks like an mx DateTime (there is a 'ticks' member, for
>example).
>
>I'm probably doing something stupid again, but I think I
>don't understand enough about how data gets loaded to figure
>it out.  I don't even understand why mdl_normalize doesn't
>convert a string into a datetime, and when it doesn't why
>things don't break.  (I suppose that could have something to
>do with the sqlite round trip.)

mdl_normalize doesn't convert from string, because that's the job of 
mdl_fromString.

The easiest way to solve your problem would be to use peak.storage type 
converters.  Add this:

    [Import on Demand]
    datetime = "datetime"

    [sqlite.sql_types]
    TIMESTAMP = lambda descr,value: 
datetime.datetime.fromtimestamp(value.ticks())

to your .ini file, and you'll get automatic conversion of TIMESTAMP columns 
to datetime.datetime.  You can define converters for any of 'DATE', 'INT', 
'NUMBER', 'ROWID', 'STRING', 'TIME', and 'TIMESTAMP'.

Note that you can do this for any DB type; PEAK DB drivers have a 
'supportedTypes' attribute that lists the type names that you can 
use.  (They vary widely among DBAPI drivers.)

Anyway, the idea is that when using SQL, you ideally do all your type 
normalization at the DB driver level, so your DM code doesn't have to deal 
with it on a case-by-case basis.  Certainly, you don't want to have to 
embed this in your domain model code if you can avoid it.