#7155 closed (fixed)
dates() querysets don't work after qsrf
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Keywords: | qsrf-cleanup post-qsrf | |
Cc: | eric@…, jdunck@…, jarek.zgoda@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
After queryset refactor merge, a .dates() DateQueryset won't work on a null=True DateField.
During query setup, the queryset adds a .filter(fieldname__isnull=True)
instead of .filter(fieldname__isnull=False)
to avoid parsing null dates, so the resulting sql returns an empty list (or raise errors if there actually are null fields in the db).
I've attached a patch that fixes the problem
Attachments (2)
Change History (18)
by , 17 years ago
Attachment: | null_dates.patch added |
---|
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Needs tests: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
I'm marking this as accepted, and the patch makes sense, however it would be nice if we could add a testcase for this regression.
comment:3 by , 17 years ago
Cc: | added |
---|
comment:4 by , 17 years ago
Cc: | added |
---|
by , 17 years ago
Attachment: | dates-qsrf-7155.diff added |
---|
Updated patch with regression test included.
comment:5 by , 17 years ago
Needs tests: | unset |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:6 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:7 by , 17 years ago
Owner: | changed from | to
---|
comment:8 by , 17 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
I've been using the patched code in a fairly complex app (production server, a few million pages etc) without any problem; now that it includes tests (thank you jeremy!), this can be probably checked in even before malcolm's return. Any core dev interested? It is, after all, an harmless on-liner :)
comment:9 by , 17 years ago
Keywords: | qsrf-cleanup added |
---|---|
Triage Stage: | Ready for checkin → Accepted |
Non-core devs should not mark things as ready for checkin.
comment:11 by , 17 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Bumping back up to ready for checkin based on Russell's note to django-dev:
http://groups.google.com/group/django-developers/msg/e8762784813b3921
where he says "If a ticket describes something that is clearly a bug, move to accepted (or ready for checkin if it's a trivial problem with a patch and tests ready to go)."
I think this one fits the "trivial" category and it has a test. It looks like at least 4 people have hit this bug and reported it in the tracker so it would be nice to have the very minor and obvious fix get into the code base.
comment:12 by , 17 years ago
Description: | modified (diff) |
---|
comment:13 by , 17 years ago
milestone: | → 1.0 |
---|
comment:14 by , 17 years ago
Cc: | added |
---|
comment:15 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Spread across 3 tickets #7145, #7147