Over the last 6 months we've been working on a fairly large refactor to
expressions. As a brief catch up, expressions are currently F()
expressions. I've expanded their scope to include Aggregates. As a
by-product of this we can now use any kind of expressions in the
.annotate() function, not just aggregates. Tim Martin has done some work
based on this patch that extends support to .order_by() also. See the
bottom of this post for links to the various discussions and patches. I
highly recommend reading them - and for 3rd party backend maintainers -
trying them out.
Although this functionality hasn't been merged into core yet, Tim and I
would like to start putting together a bunch of SQL functions to be
included in django. There exists a type called Func in the new
implementation that allows us to create very simple classes that implement
SQL functions:
class Lower(Func):
function = 'LOWER'
The API documentation goes a long way in explaining all the various ways
that custom expressions and functions can be built, so I'll avoid that for
now. What we are looking for is some interest in the implementation and
what we should try to include. I'm not sure, but this might be the perfect
opportunity to create a DEP.
1. What SQL structures and functions should we try to support for initial
release? We need to compose a list of everything we should implement and
commit to. Some examples:
LOWER/UPPER/COALESCE/CASE,WHEN or IF/SUBSTRING etc. I believe we should be
able to implement analytical/window functions too, but that might be best
left to a future release or even a third party library.
2. Where should these functions live? Currently everything exists in the
django.db.models.expressions namespace (aggregates are still in
models.aggregates). I'm thinking along the lines of
django.db.models.functions?
3. How should we support the built in backends where differences in
implementation arise? As a bad example, what if Oracle requires uppercase
`LOWER()` and Postgres requires lowercase `lower()`. Expressions have the
concept of `as_{vendor}`, which allows 3rd party backends to provide their
own implementation of an expression. Should we use this extension point
internally, or should we continue to put any differences we find directly
in the backend? I think it'll be easier to support the as_vendor structure,
and will automatically support 3rd party backends rather than forcing them
to implement lower_or_uppercase_function_feature per backend.
4. Should these functions be part of core, or should they be built as third
party or even contrib apps? I think backend specific functions could find a
home in contrib (like the postgres kickstarter) or as third party
libraries. But we should implement the basics/most common.
5. Are we jumping the gun and should we wait until the patches land before
even discussing the above?
I'll leave it there for now. Hopefully we can get some good feedback and go
from there.
- Josh
*Links:*
Annotations/Aggregation support:
- https://groups.google.com/forum/#!topic/django-developers/8vEAwSwJGMc
- https://github.com/django/django/pull/2496
Order By support:
- https://groups.google.com/forum/#!topic/django-developers/arR7B_Luszc
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/6b028bd2-bb84-4a68-bc70-705ae3d1d9e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
