#7530 closed (fixed)
Related objects are not None like they should be
Reported by: | Owned by: | Malcolm Tredinnick | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Design decision needed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Attachments (1)
Change History (7)
by , 17 years ago
Attachment: | django_related_null_fields_fix.patch added |
---|
comment:1 by , 17 years ago
milestone: | → 1.0 alpha |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
comment:2 by , 17 years ago
IIRC empty instances for remote models did not exist in Django 0.9x. If objects had a NULL
value in the database they were mapped to None
values in Python, not to object instances with all fields set to None
.
So this is a behaviour change from Django 0.9x. I am not sure which changeset caused it (the above changeset number is just a guess) but before the queryset-refactor merge, empty instances were not created, and now they are.
comment:3 by , 17 years ago
milestone: | 1.0 alpha → 1.0 |
---|
According to ticket organization defined in http://code.djangoproject.com/wiki/VersionOneRoadmap#how-you-can-help 1.0 alpha tickets should be just features in the Must have (http://code.djangoproject.com/wiki/VersionOneRoadmap#must-have-features) list.
As bug, it should be fixed before 1.0 milestone.
comment:4 by , 16 years ago
Owner: | changed from | to
---|
comment:5 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Have you actually checked to see if the ticket/patch references caused this behavior? As I recall, the functionality of the system was the same before and after that ticket (I was annoyed by the behavior you're describing here before I generated that patch), it would create the model with all empty fields, and the patch itself has nothing to do with model creation of the related fields. Be careful when you indicate a specific patch as the fault of something, as it might mislead the triagers/core devs.
That having been said, I agree that it would be preferable to have the behavior you're describing here in general. It will screw up the code of people who are depending on an empty instance of the remote model existing however, so I'm promoting it to DDN as it breaks backwards compatibility. I'm also taking the liberty of marking it as a 1.0, as it's a large enough feature decision that I believe it needs to be handled before we do our public release. I'll give a +0 on it.