> However, I think having some special case code in filter(), annotate()
and anything else that takes expressions would be OK
I strongly disagree with this. Expressions are context insensitive at the
moment, which means they can be used anywhere. If we start externalising
behaviour based on the context of use, it'll lead us to some very confusing
code and a tonne of special cases. It would be slightly better if you could
check the context from the `prepare()` method (are we preparing order_by or
not), but then I think we'll run into issues where the prepare breaks for
3rd party backends - by checking private data. I really do think we'd be
better off documenting that __neg__ is reserved by Expressions for
Ordering, and leave it at that.
I'm surprised how easily expressions slotted in to the order_by - I thought
it'd take a lot more work. Good stuff I think. Some questions:
- should expressions in order_by support random ordering (?) ? I don't
think so, but I haven't ever had a need for random ordering so I'm not sure.
- could we reduce the complexity of the order_by machinery by forcing all
arguments (internally) to be expressions? `order_by('field_a') ->
order_by(F('field_a'))` etc
These are open questions, not necessarily directed at Tim.
> I haven't yet implemented the LowerCase and related functions
I think we can build out a handy little library of utility functions like
Lower and Coalesce that could(should) be included directly in django. But
it'll also open up, to library developers, the ability to easily develop
backend specific structures, similar to parts of the
django.contrib.postgres kickstarter.
Cheers
On Tuesday, 10 June 2014 06:31:28 UTC+10, Tim Martin wrote:
>
> On Monday, 9 June 2014 21:28:51 UTC+1, Tim Martin wrote:
>>
>>
>> On Monday, 9 June 2014 20:44:08 UTC+1, Tim Martin wrote:
>>>
>>>
>>> I'll go ahead and try to implement this using __neg__() to invert the
>>> ordering.
>>>
>>>
>> It's still pretty rough, but there's some code in
>> https://github.com/timmartin/django/tree/order_by_expressions that
>> appears to work. In particular, I haven't yet implemented the LowerCase and
>> related functions (I have one, but it's just a test hack), but that should
>> just be boiler-plate.
>>
>>
> And I should have noted that I haven't implemented detection of negation
> in contexts other than ORDER BY. It's not easy to do it cleanly with the
> simple approach I've got at the moment. The code could just check that
> get_ordering() returns ASC, but a) that's gross and b) it doesn't solve the
> problem of having unary negative on a subexpression, which would get
> ignored.
>
> Tim
>
--
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 [email protected].
To post to this group, send email to [email protected].
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/3f909f23-00a5-4bec-a21c-1333cec912b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
