because an attribute can be mapped to multiple columns,
i.e.http://www.sqlalchemy.org/docs/orm/mapper_config.html#mapping-a-class
Ahh... thanks.
as I did this example and thought back upon how often people want to poke
around the mapper configuration, i started trying to think of how
On Jul 2, 2011, at 2:25 PM, Russ wrote:
I know very little about your internal implementation, but I might as
well toss a thought out there on navigating a mapper configuration...
it would be more intuitive/explicit to me if there were a
DbColumnProperty base class, and two derived
On Jul 1, 2011, at 1:19 AM, Russ wrote:
The only thing I'm still unsure of in the code is why mapper.columns
is a collection and it required checking columns[0], but I can either
just live with that or look into it later.
because an attribute can be mapped to multiple columns, i.e.
I discovered the sqlalchemy.orm.validates decorator, which executes
when I want it to (on attribute assignment) so I got out my hacksaw
and tried to make it work in one fell swoop... implementing automatic
UTC assignment for all UTCEnforcedDateTime columns.
I'm not comfortable with it yet... but
you're close, I've added a note to the validates documentation at
http://www.sqlalchemy.org/docs/orm/mapper_config.html#simple-validators that
will point a reader on to the more comprehensive solution.
I've added an example for you as well as Jason who asked almost the same
question earlier,
I've added an example for you as well as Jason who asked almost the same
question earlier, which illustrates the TypeDecorator in conjunction with an
attribute listener that is applied to all occurrences of the target type, an
approach also used by the mutable attributes extension, and
When I realized that process_bind_param only happens on commit, I
decided to switch my strategy to simply confirming that all incoming
outgoing datetime values are offset-aware UTC using this simpler code:
http://pastebin.com/gLfCUkX3
Sorry - I messed up that code segment on edit for
