On Wednesday, September 21, 2011 4:16:07 PM UTC-4, guruyaya wrote: > > This is what I got. No fix, for now. > Say you have a datetime field. The database adapter will save it as a > TIMESTAMP sqlite type. > Now if you decide you just want the date, you don't care for the time. > You change the field to be a date col. But SQLite still use the > TIMESTAMP field type. At this point, it converts timestamp to date, as > part of what the python sqlite adapter tells it to do, and that line > has a bug, that creates the ValueError. > > I have no idea how 1.98.2 can go around this. It seems more an sqlite > bug, then a web2py bug. Yet - the problem remains. > Hope someone will have a better idea what's going on here. >
This is the result of a change I was pushing for, which makes sqlite behave more like every other database - by asking it to parse the date or timestamp field itself, rather than return a string. Your database itself is in a actually in an inconsistent state -- if you dumped it to .csv and reloaded, you will not get the same database; if you tried to dump and reload into Postgres, you wouid fail. The previous web2py behavior somehow shielded you from that, but that's sort of a lucky coincidence for you; If you changed the column type from a 'decimal' to an 'int' and had float values, you'd be in the same trouble; or even worse if you changed from a 'string' to an 'int'. Massimo might back the change out, but if he does not, you can force a return to sqlite's previous behaviour by changing from db = DAL('sqlite:....') to db = DAL('sqlite:...', driver_args={'detect_types': 0}} Either way, I would think it's a good idea for you to make the database consistent -- things like this tend to byte in more than one way.