#22394: Several built in Lookups should actually be Transforms
-------------------------------------+-------------------------------------
Reporter: smeatonj | Owner: mjtamlyn
Type: Uncategorized | Status: assigned
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: lookups | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by mjtamlyn):
* status: new => assigned
* owner: nobody => mjtamlyn
Comment:
Doing something with this issue is part of my kickstarter, so it would
probably be unfair for someone else to work on it.
I believe the current machinery is enough to provide "optimal" queries in
all circumstances. This will work by making `__year` a `Transform` which
is actually a no-op, and that transform having a set of lookups available
to it distinct from the normal lookups, which each both extract the year
*and* do the comparison. This allows us to use `EXTRACT` for the exact
case but not for the less than case (for example). (Note that if `__year`
becomes a transform all calls to `__year` explicitly become
`__year__exact`). At present, lookups and only used in filter queries. We
will need to be more intelligent here when considering their use in values
calls, custom index etc as then a `__year` transform cannot be a noop.
To work out the best option for each possible call here, I will be running
benchmarks and checking query plans, with and without indexes, for all the
possible queries. We can then work out what the best query is for each db
in each case - they need not necessarily be the same.
It is also possible with custom indexes that there may be a case for the
`__year` transform having a `__extract` transform which forces the use of
`EXTRACT()` at SQL level. This would be an unusual use case for year, but
perhaps more likely for `__date` or `__week` where a user could add an
index for this particular extract and then perform efficient queries using
it without needing to index the entire table. This could be much more
efficient with logging-like tables, but until I try it out I don't know.
--
Ticket URL: <https://code.djangoproject.com/ticket/22394#comment:2>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.d8461224ad91010a357852c33fd06d26%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
