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.