this particular feature is easily implemented right now as an end user recipe, using TypeDecorator. no new type system is needed for this one (although there is a ticket for such).
the advantage to TypeDecorator is that you get to define what kind of date representation you'd like to convert from/to, i.e. a particular string representation, mxDateTime, etc. that the string format of "MM/DD/YYYY HH:MM:SS" just happened to work doesnt seem to me to be terribly useful, considering that if you were in some other country the date would be entered as "DD/MM/YYYY" or such. hardcoding in a "YYYY-MM-DD HH:MM:SS" format into the code doesnt seem like such a "solution". On Aug 8, 2007, at 5:36 PM, Rick Morrison wrote: > FYI I believe there is a ticket to make improvements in the type > system that would allow strings to be given as date input (among > other conveniences), and I don't think it's a bad thing. Lots of > databases make the conversion anyway, and it's ultimately pretty > confusing thing to have various Dialects treat data in various ways. > > I've been bugging Mike for a long, long time about a better type > system, and I think I may have oversold it and made it sound too > big and grandiose. All it needs to be is a layer that adapts the > incoming type to the desired column type. This case would be a good > example, the incoming string would be converted into a datetime (or > whatever the Dialects's DBAPI needed) and sent to the database that > way. Conversely, when fetching data, the Dialect could adapt the > data back to the standard Python type for the column (as it is > pretty much already done). > > IMO this is going to become increasingly important with SA being > used for data migration as we've recently seen (thanks to you) and > with upcoming sharding support. Type differences in those cases can > make life hell. > > Rick > > > On 8/8/07, Paul Johnston <[EMAIL PROTECTED]> wrote: > > Dave, > > > I recently upgraded from SQLAlchemy 0.3.8 to 0.3.10. The only > >problem I ran into is that 0.3.10 no longer allows you to set > datetime > >columns using strings. > > > > > What database are you using? I did some rework around MSSQL and dates > between those versions. > > You now need to use datetime.* objects; it was a bug that it > previously > allowed strings. The problem with string is that it makes you > dependent > on the date format configured in the database. This had caused me a > problem is live app - when the damn database got rebuilt and > configured > a little differently. > > Paul > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
