Opened 12 years ago
Closed 12 years ago
#18969 closed Bug (duplicate)
ORM filtering with "year" lookup for dates
Reported by: | saippuakauppias | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Türker Sezer, tomas.ehrlich@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When I do query with lookup in orm:
Document.objects.filter(given_on__year=1).values_list('given_on', flat=True)
or
Document.objects.filter(given_on__year='0001').values_list('given_on', flat=True)
I get results:
[datetime.date(2012, 8, 31), datetime.date(2012, 8, 31), datetime.date(2012, 8, 29), '...(remaining elements truncated)...']
But I would expect dates in interval 0001-01-01 ... 0001-12-31 (YYYY-MM-DD).
Generated SQL query:
print Document.objects.filter(given_on__year='0001').values_list('given_on').query
SELECT "documents_document"."given_on" FROM "documents_document" WHERE "documents_document"."given_on" BETWEEN 1-01-01 00:00:00 and 1-12-31 23:59:59.999999 ORDER BY "documents_document"."created_on" DESC
In django not possible give results with first year.
PS: question in stackoverflow
PPS: tested in Django 1.3.2 version
Attachments (2)
Change History (9)
by , 12 years ago
Attachment: | 18969.patch added |
---|
comment:1 by , 12 years ago
Cc: | added |
---|---|
Has patch: | set |
comment:2 by , 12 years ago
Component: | ORM aggregation → Database layer (models, ORM) |
---|---|
Needs tests: | set |
Triage Stage: | Unreviewed → Accepted |
Version: | 1.3 → master |
comment:3 by , 12 years ago
Cc: | added |
---|---|
Needs tests: | unset |
I'm just unsure if wrote the test right. I've added new fixture (for date 0001-01-01) at the bottom of existing test (test_date_lookup) and related assertion, so I don't have to rewrite any previous assertions… Usually are fixtures at the top of the test. Does it matter?
comment:4 by , 12 years ago
Cc: | added |
---|
This issue seems fixed already, your test case works for me on sqlite and postgres using the current master, the sql is generated correctly.
I'm not sure about the position of the test date generation, but you could create an article with datetime.datetime(1, 3, 3)
and it wouldn't mess with the previous assertions.
Could you upload a patch with the test case only? Or even better, create a pull request on github?
This ticket describes a bug similar to #18176
comment:5 by , 12 years ago
Cc: | removed |
---|
I've created a pull request with your test and updates to the queryset documentation (the __year, __month
, .. lookups accept integers and strings), see #18176: https://github.com/django/django/pull/841
comment:6 by , 12 years ago
If the current implementation happens to accept strings, fantastic. But I'm against documenting it — because it means committing to support strings in these lookups forever.
Years, months, and friends are fundamentally integers and "there should be one-- and preferably only one --obvious way to do it."
comment:7 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Closing as a duplicate of earlier ticket #18176.
Attached patch fixes this issue for all common db backends