this direct yourmodels.DateType replacement would work if u had that in some
separate file, and all your models imported from that one. But, as there's
probably lots of other code and the import DateTime is probably everywhere, i
dont think u know which DateTime's to be replaced and which not.
if u want to replace _all_ of them, just make name the BananaType
module "datetime" and put that module in the beginning of PYTHONPATH. Or,
replace the original's datetime.DateType.. These would work if the BananaType
really emulates DateType so other non-DB things would not break. Which i
doubt - say if u have XMLRPC, pickle/unpickle or similar materializations.
so i guess, explicit is better than implicit - u generate them anyway.. But
this won't save you from checking the other usages of DateTime.
On Saturday 25 April 2009 01:18, phrrn...@googlemail.com wrote:
> 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, "phrrn...@googlemail.com"
>
> <phrrn...@googlemail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
