On Aug 21, 2008, at 5:07 AM, Harish K Vishwanath wrote:
> Hello, > > I have a class defining our own data type : > > class RsiSqliteDateTimeType(types.TypeEngine): > def __init__(self): > pass > > def get_col_spec(self): > return "VARCHAR(35)" > > def convert_bind_param(self, value, engine): > if value != None: > return value.ToString() > return None > > def convert_result_value(self, value, engine): > if value != None: > return dtime.CIRDateTime(value) > return None > > CIRDateTime() is a custom written DateTime class. > > Now, a few of my test cases which would pass thru SQLA 0.4.6 is > failing in SQLA 0.5beta4dev (latest trunk). It basically involves a > lesser than comparision between CIRDateTime() object picked from > SQLite database vs a newly passed CIRDateTime() object. > > in SQLA 0.4.6 : > > (CIRDateTime from Sqlite) < CIRDateTime() #returns the current > datetimestamp > >>> True > > in SQLA 0.5beta4 latest trunk : > > (CIRDateTime from Sqlite) < CIRDateTime() #returns the current > datetimestamp > >>> False > > I am still trying to find out why this anomaly is occuring. I went > through the 0.5 migration guide, which talks about changes in the > way milliseconds are stored on SQLITE, but this is my user defined > data type. Could there be any difference between the two versions? there's no difference in behavior at the level you describe. If SQLA's DateTime object is not in use within your application, then the changes to that object from 0.4 to 0.5 will not impact the behavior of your app. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
