[Django] #25556: Add DatePart db expression to allow complex lookups on date parts (e.g. year, month, day)
Django
year, month, day)
----------------------------------------------+----------------------------
Reporter: ryuusenshi | Owner: nobody
Type: New feature | Status: new
Component: Database layer (models, ORM) | Version: 1.9a1
Severity: Normal | Keywords: db expressions
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 1 | UI/UX: 0
----------------------------------------------+----------------------------
Currently it is not possible to filter by matching the year/month/day part
of two separate date fields.
I propose something to the effect of:
{{{
from django.db.models.expressions import DatePart
MyModel.objects.filter(date1__month=DatePart('date2', 'month'))
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25556>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
year, month, day)
------------------------------------------+----------------------------
Reporter: ryuusenshi | Owner: nobody
Type: New feature | Status: new
Component: Database layer (models, ORM) | Version: 1.9a1
Keywords: db expressions | Triage Stage: Unreviewed
Has patch: 1 | Easy pickings: 1
UI/UX: 0 |
Changes (by ryuusenshi):
* Attachment "expressions_patch.py" added.
django.db.models.expressions patch
Django
year, month, day)
Reporter: ryuusenshi | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: db expressions | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by ryuusenshi):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I've added a pull request, but I'm unsure about the tests. I've looked for
similar tests for the Date and DateTime expressions and I couldn't really
find any. The only existing tests are found in `tests.expressions.tests`
and they're only testing the repr.
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:1>
Django
year, month, day)
Reporter: ryuusenshi | Owner:
| ryuusenshi
Type: New feature | Status: assigned
Component: Database layer | Version: 1.9a1
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by ryuusenshi):
* owner: nobody => ryuusenshi
* status: new => assigned
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:2>
Django
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
Changes (by ryuusenshi):
* Attachment "expressions.diff" added.
Django
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
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
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
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
Changes (by jarshwah):
* cc: josh.smeaton@… (added)
* needs_better_patch: 0 => 1
* needs_tests: 0 => 1
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:4>
Django
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: 1
Easy pickings: 1 | UI/UX: 0
Comment (by akaariai):
I'm not too happy with adding this to 1.9. If we were only to document
existing code that would be OK for me, but we are doing a bit more here.
Accepting new features because they change so little is a slippery slope.
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:5>
Django
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: 1
Easy pickings: 1 | UI/UX: 0
Comment (by jarshwah):
The DateTransform + DatePartTransform classes were all added in 1.9. I
would really like to at least change their names to remove the `Transform`
part of the name at a minimum. I agree that adding new features is a
slippery slope. How do you feel about renaming these classes during the
alpha though?
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:6>
Django
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: 1
Easy pickings: 1 | UI/UX: 0
Comment (by akaariai):
I don't mind the renaming. The pre-release period is for polishing new
implementations.
I guess I withdraw my objection about 1.9. We are doing two things here:
1. Changing some names. We are going to do this no matter if we add
documentation for this.
2. Adding the date expressions as a new feature by documenting existing
code.
Doing 2. alone doesn't seem too bad. We aren't doing any code changes for
the feature. So, I don't object, but I still think we should be extremely
careful in not making the feature freeze a debatable issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:7>
Django
year, month, day)
Reporter: ryuusenshi | Owner:
| ryuusenshi
Type: New feature | Status: assigned
(models, ORM) |
Severity: Normal | Resolution:
Keywords: db expressions | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
-------------------------------------+-------------------------------------
Changes (by timgraham):
* version: 1.9a1 => master
* easy: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:8>
Django
year, month, day)
Reporter: ryuusenshi | Owner:
| ryuusenshi
Component: Database layer | Version: master
(models, ORM) |
Keywords: db expressions | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by timgraham):
* status: assigned => closed
* resolution: => duplicate
Comment:
Duplicate of #25774 as far as I can tell.
--
Ticket URL: <https://code.djangoproject.com/ticket/25556#comment:9>