Opened 18 years ago
Closed 18 years ago
#2608 closed defect (fixed)
multi-level foreignkey throws KeyError
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
Component: | contrib.admin | Version: | |
Severity: | minor | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Example models:
class person(models.Model): pid = models.CharField(maxlength=20, primary_key=True) name = models.CharField(maxlength=100) class student(models.Model): student_pid = models.ForeignKey(person, db_column='student_pid', to_field='pid') class student_option(models.Model): pid = models.ForeignKey(student, to_field='student_pid') junk = models.IntegerField()
Note that student_option pid refers to student_pid which itself is a ForeignKey on student pointing to person.
Trying to generate SQL for these models throws KeyError: 'ForeignKey'
It appears that FKs are not allowed to point at a datatype that is itself a FK. It would be nice to allow multi-level foreign keys as there is a benefit in modeling legacy data with this kind of schema.
The patch attached simply enables the creation of SQL necessary for this to happen, by recursively diving down until we find the real underlying datatype.
Attachments (2)
Change History (4)
by , 18 years ago
Attachment: | multilevel_fk_patch.txt added |
---|
by , 18 years ago
Attachment: | multilevel_fk_patch.patch added |
---|
comment:1 by , 18 years ago
Triage Stage: | Unreviewed → Ready for checkin |
---|
Although this is an obscure use-case, I validated that this does raise the above exception and that the patch fixes this.
comment:2 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
slightly simpler patch