#25556: Add DatePart db expression to allow complex lookups on date parts (e.g.
year, month, day)
-------------------------------------+-------------------------------------
Reporter: ryuusenshi | Owner:
| ryuusenshi
Type: New feature | Status: assigned
Component: Database layer | Version: 1.9a1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: db expressions | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by jarshwah):
I was sure there was already a ticket addressing this feature but I can't
seem to find it just yet. Accepting based on not being able to find a
duplicate.
As to the implementation though, as of Django 1.9 (in alpha right now)
transformations such as `__month` `__year` etc can be used on the right
hand side of lookups. There's no need to create new expressions.
`django.db.models.lookups` provides `DateTransform` as well as things like
`MonthTransform` and `MinuteTransform`. So it's already possible to use
private classes to achieve the outcome you're after. These transformations
also work correctly with Time/DateTime/Date fields and have timezone
support.
{{{
from django.db.models.lookups import MonthTransform
MyModel.objects.filter(date1__month=MonthTransform('date2'))
}}}
I don't love the class names though and we should definitely document
these date based transforms.
So let's:
- rename datetime based `XTransform` classes to `X`.
- document these classes somewhere (in expressions.txt or a new docs
module?)
- test that they definitely can be used on the right hand side
- add to release notes
Optional/Undecided:
- Move these classes into a separate submodule and import them from
lookups.py to ensure they're registered
- Change DateTransform to also accept a `lookup_name` in `**kwargs` so
`DateTransform('field', lookup_name'month')` will work. This should also
be renamed to something more appropriate, like `Extract()` ? `DatePart` is
also a descriptive name.
Should we allow this into 1.9? It doesn't change any public api as these
classes were only introduced for 1.9 in the first place. I would say yes,
we should do this for 1.9.
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.1628fb656408f4a42afb2c4dad9ba27a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
