Code

Opened 4 years ago

Closed 4 years ago

#13966 closed (invalid)

sqlite orm problem with dates

Reported by: leszek0140 Owned by: nobody
Component: Database layer (models, ORM) Version: 1.2
Severity: Keywords: date, orm, sqlite
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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

Attachments (0)

Change History (2)

comment:1 Changed 4 years ago by carljm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

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.

comment:2 Changed 4 years ago by mtredinnick

  • Resolution set to invalid
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.