#16187: Refactor lookup system
-------------------------------------+-------------------------------------
Reporter: UloPe | Owner: UloPe
Type: | Status: new
Cleanup/optimization | Version: 1.3
Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 0
Keywords: | Patch needs improvement: 1
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by Alex):
So here's my idea for how custom field lookups should work (not
necessarily related to this ticket):
(1) First the Query identifies the root object of the lookup, this should
either be a field, or an aggregate I think.
(2) Then, it traverses the remaining bits, at each section it calls a
method on the return value from either part 1, or the previous item in
part two. This method should return a representation of the next step, so
for example an `fkey__field` would return something that says "I am a
field traversal", and it could raise some exception to bail out (in
particular this should be used on the final step, in order to indicate
that an `__` lookup like `__lt` should use the comparison operator).
(3) Finally the last step of this should add itself to the query. In
theory this calls for an even bigger refactor, because really it should
add itself to the compiler at the very end, but I'm not sure if that's
possible ATM, and it shouldn't block this happening.
--
Ticket URL: <https://code.djangoproject.com/ticket/16187#comment:7>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
