Code

Opened 3 years ago

Closed 3 years ago

#15842 closed Bug (wontfix)

Silent Failure of InlineAdmin Class With a DateTimeField on the Model if Only a "time with timezone" Column in the Database

Reported by: vincitveritas Owned by: nobody
Component: Database layer (models, ORM) Version: 1.2
Severity: Normal Keywords:
Cc: vincitveritas Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX:

Description

Ok, this is definitely an edge case, but I ran into this when trying to update a model to add another DateTimeField in one of my projects with an existing database in place. I tried to manually create the db column (postgres), but inadvertently did a "time with timezone" column type instead of "timestamp with timezone". I then went to test the code change on the site's admin. Everything seemed fine, until I actually entered a date and time for the field. The next time I loaded up the admin change page, the inline for that particular inlinemodeladmin just wasn't there. So, I went into the shell and deleted the value from the field and saved. Then, I reloaded the admin change page. Et voila, the inline returned. After much head scratching, I realized what I had done and dropped the incorrectly typed column from the db table and re-created it with the correct type. I was then able to set the value and the inline showed up as expected.

What concerns me is that no error was raised by the mismatch between the DateTimeField declaration in the model definition and the incorrectly-typed db column, only the disappearing inlinemodeladmin. Something just doesn't seem right there.

Attachments (0)

Change History (2)

comment:1 Changed 3 years ago by vincitveritas

  • Cc vincitveritas added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 3 years ago by aaugustin

  • Easy pickings unset
  • Resolution set to wontfix
  • Status changed from new to closed

Generally Django does not attempt anything to warn you of inconsistencies between your models and your database.

Even something as gross as replacing a TextField by an IntegerField will only result in exceptions at runtime, possibly in unexpected places.

It is hard to debug, but I think it is a consequence of (1) Python's type handling and (2) Django's choice not to use database introspection.

Solving this problem would require some database introspection. I think the core devs will reject the idea, but you can always bring it on django-developers to be sure.

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.