Now you've said it, having both seems reasonable to me too :)
On 23 December 2017 at 17:42, Shai Berger wrote:
> On Tue, 19 Dec 2017 17:58:35 +
> Adam Johnson wrote:
>
> > Fair. I agree it's more flexible, but it does make "the most common
> > case" of extending the ordering pretty long-win
On Tue, 19 Dec 2017 17:58:35 +
Adam Johnson wrote:
> Fair. I agree it's more flexible, but it does make "the most common
> case" of extending the ordering pretty long-winded:
>
> ordering = qs.get_ordering()
> ordering.append('new_field')
> qs = qs.order_by(*ordering)
>
I don't object to h
Thanks, Adam!
On Tuesday, December 12, 2017 at 2:40:11 AM UTC+5:30, Markus Holtermann
wrote:
>
> Hi all,
>
> I'm in the situation where I'd like to join two .order_by() calls on a
> QuerySet without losing the ordering set by the first call.
>
> This was formerly discussed in https://code.django
Mithlesh, that's off-topic for this thread. But Django doesn't have it's
issues on GitHub, it has them on Trac at https://code.djangoproject.com/ .
See https://docs.djangoproject.com/en/dev/internals/contributing/ for a
comprehensive guide on contributing.
On 19 December 2017 at 17:58, Adam Johnso
Fair. I agree it's more flexible, but it does make "the most common case"
of extending the ordering pretty long-winded:
ordering = qs.get_ordering()
ordering.append('new_field')
qs = qs.order_by(*ordering)
On 18 December 2017 at 21:33, Shai Berger wrote:
> On Fri, 15 Dec 2017 21:01:39 +
> A
>
> Can you please tell me where the issues of django are in GitHub ?
>
Thanks
Mithlesh K
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it
On Fri, 15 Dec 2017 21:01:39 +
Adam Johnson wrote:
> I would prefer the QuerySet method than documenting parts of Query -
> QuerySet shouldn't have to make guarantees that its interactions with
> Query won't change, plus making Query in some way a public API could
> hamper features. Plus the
I would prefer the QuerySet method than documenting parts of Query -
QuerySet shouldn't have to make guarantees that its interactions with Query
won't change, plus making Query in some way a public API could hamper
features. Plus the amount of code is small and contained.
Also I think worrying abo
Thanks for the input, Shai. I'd like to keep the current behavior
around. So .order_by(None) would still reset the ordering as-is.
But I agree, if we'de exposing QuerySet.query.order_by through a
documented API that would work for me as well (in fact, I'm using that
right now to work around the is
Seems like a good idea to me, I've been in a similar situation before and
had to work around this part of QuerySets.
On 11 December 2017 at 21:10, Markus Holtermann
wrote:
> Hi all,
>
> I'm in the situation where I'd like to join two .order_by() calls on a
> QuerySet without losing the ordering
Hi Markus and all,
My instinct is that it's better to just make sure it's easy to find the current
ordering on a queryset. I suspect the use-case for modifications is not super
common, and I'd rather not bother with specifying the exact behavior of
nonsense cases like order_by(None, append=True
Hi all,
I'm in the situation where I'd like to join two .order_by() calls on a
QuerySet without losing the ordering set by the first call.
This was formerly discussed in https://code.djangoproject.com/ticket/9415 .
I agree that simply changing the current behavior is not going to fly due
to it
12 matches
Mail list logo
