sqlite orm problem with dates

[leszek0140]

I made sqlite database manually. I defined date field with text type. Than defined that field as DateTimeField in models.py.
Finally I had problem with dates in program and I checked that type of this attribute in model instance was unicode.
Attribute started to be datetime after I had changed in sql script "text" to "datetime" and that was solution.
This behaviour seems buggy to me. It seems that definition from models.py is more important than type in dynamically typed sqlite database.

I used Django-1.2.1-5.fc12

[Carl Meyer]

When instantiating models from a database query, Django relies on the database backend to provide the correct Python types; Field instances do not currently get a chance to normalize the data. Each database backend handles this a bit differently; in the SQLite case, it uses the register_converter method provided by pysqlite to register Python coercion functions for the appropriate SQLite column types (see db/backends/sqlite3/base.py).

There is at least one comment in the Django codebase already mentioning that it would be cleaner to give Fields a chance to normalize the data from the database (​in the Oracle backend). Given the existence of that comment, and the reporter's point (date and text field are indistinguishable in SQLite in terms of behavior, shouldn't the model field define what the model data attribute ends up like) a design decision may be needed here? In that case, the summary should be changed to reflect the broader issue of normalizing data from the database backends.

Otherwise, this should be closed wontfix, as it isn't fixable without the bigger change.

[Malcolm Tredinnick]

The problem description is that when you put the wrong Django field over a particular database field (DateTime's don't sit over the top of text database columns), things behave unpredictably. This isn't a bug in Django. AS noted, creating the correct database column type returns things to normal behaviour. We shouldn't have to work around user errors of this nature as it's on the same level as MySQL + MyISAM not enforcing referential integrity. If you do something silly, you bear the consequences.