My manager came up with a rather clever -- if not devious --
suggestion: implement the type adapators as usual but then diddle the
namespace of the package where the SA model is defined. I tried it and
it works but is sufficiently confusing that I am now in favor of
changing the models so that the columns explicitly reference the
appropriate decorator. The main objection was the use of a specialized
type in such an indiscriminate fashion. However, since most of the
models are code-generated, I can write it off as yet another
convention in place in the code.
pjjH
# Here are the decorators
class BananaDate(types.TypeDecorator):
impl = types.Date
def process_result_value(self, value, dialect):
from deshaw.datetime.date import Date
return Date(value)
class BananaTimestamp(types.TypeDecorator):
impl = types.DateTime
def process_result_value(self, value, dialect):
from deshaw.datetime import timestamp
ts = timestamp.Timestamp()
return ts.from_parts(value.year, value.month, value.day,
value.hour, value.minute, value.second, value.microsecond)
=== in the model file ===
# here in the model file, import the type decorators but aliased to
the corrosponding SA types
from banana.dbo import BananaDate as Date
from banana.dbo import BananaTimestamp as DateTime
On Apr 24, 5:00 pm, "[email protected]"
<[email protected]> wrote:
> My employers have a custom Python type (derived from datetime) for
> dealing with dates and datetimes.Let's call it 'BananaDate'. They
> would like BananaDate be used by SQL Alchemy. The standard way of
> doing this appears to be with a TypeDecorator:
>
> class BananaDate(types.TypeDecorator):
> from banana.date import Date
> impl = types.Date
>
> def process_result_value(self, value, dialect):
> return banana(value)
>
> I understand that the Column definitions would change from:
>
> Column('first_reset_dt', DateTime, nullable=True)
>
> to
> Column('first_reset_dt', BananaDate, nullable=True)
>
> These seems to imply that I have to explicitly change the models (and
> I would prefer not to do that)
>
> Is there some neat 'hook-based' approach that would allow me to leave
> the metadata models intact and yet work with BananaDates? Would it be
> very rude to monkey-patch the relevent base types in sqlalchemy.types
> with new definition of process_result_value?
>
> pjjH
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
