#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 , 16 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 |
Note:
See TracTickets
for help on using tickets.
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.