OK, so it's the database driver that should make sure values suit the
columns they are bound to, but @validates allows me to do it too. Makes
perfect sense — thanks!
Regards,
- Gulli
On Thu, Mar 12, 2009 at 2:28 PM, Michael Bayer <mike...@zzzcomputing.com>wrote:
>
> Gunnlaugur Briem wrote:
> >
> > Hi,
> >
> > I get away with stuffing datetime.datetime.now() into a DateTime
> > (timezone=True) column, despite the former being timezone-naive
> > (.utcoffset() is None, .tzinfo is None, etc.).
> >
> > It is stored in the table with UTC offset +00, which is arguably
> > incorrect (states information that was not present in the input).
> >
> > But even if you call it correct, you get in trouble when you read the
> > value back as an attribute of a mapped class in a session, set the
> > attribute again to datetime.datetime.now() (again timezone-naive), and
> > then try to query the session for the same object again. This retches
> > up a TypeError: “can't compare offset-naive and offset-aware
> > datetimes”.
>
> SQLA doesn't process datetime objects at all when using the postgres
> dialect - psycopg2 supports datetime objects directly and sqlalchemy
> passes them straight through. you should use only timezone-aware
> datetime objects if you are dealing with a column of that type. If you'd
> like to add validation or processing specific to your use case, you can
> use the @validates decorator at the ORM level or the TypeDecorator at the
> table metadata level to provide whatever rulesets you'd like.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
