Opened 13 years ago

Closed 12 years ago

#2111 closed defect (wontfix)

Admin site can't deal with broken ForeignKeys

Reported by: peter.harkins@… Owned by: Adrian Holovaty
Component: contrib.admin Version:
Severity: normal Keywords: admin, foreignkey
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I'm using Django's admin site to interface to an existing database that does has some broken ForeignKey references. Instead of the admin site allowing me to edit and correct these records, I can't even browse them. When the admin interface should display the "Select [model] to change" menu I get a Django error page with the exception "DoesNotExist: [model] matching query does not exist."

Change History (4)

comment:1 Changed 13 years ago by mir@…

Normally, the database protects its foreign key references when you have declared them as such. So, this is not a common case. (How the heck did this happen, anyway?)

I don't think this ticket has a real chance to get resolved. Their is an assumption everywhere in the code that foreign keys match to something, and it doesn't make sense to change this. The users mailing list might get you a better response.

comment:2 Changed 12 years ago by peter.harkins@…

Unfortunately, the version of MySQL I'm stuck on doesn't enforce FKs. Some folks seem not to mind breaking FK relationships, and the admin interface is going to be the only way users have of correcting or deleting broken data.

comment:3 Changed 12 years ago by Simon G. <dev@…>

Triage Stage: UnreviewedDesign decision needed

Trust MySQL to be difficult :) Is there any way that this can be handled gracefully?

comment:4 Changed 12 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: newclosed

I think this is outside the scope of the admin interface. Repairing database integrity is a bit database-specific and something that has to be done at another level, usually with special tools. The admin interface assumes the persistent store is going to be well-behaved underneath it and adding special checks in for all the (very rare) cases where that might not happen will just complicate the code.

Note: See TracTickets for help on using tickets.
Back to Top