My understanding of why you wouldn't want to support using both kwargs at
the same time is that it would negate any performance gains from using the
DB's delete.
DB_CASCADE has the advantage of not making django run extra queries against
every model relation to determine which other tables nee
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
You asked me to join in on this conversation as I had an issue using Django
1.11. My third party apps do not yet all support Django 2.0.
I have an unmanaged model that is connected to a view in PostgreSQL. I
attempted to create an annotated version of the model manager using the
.annotate() m
In case there's an ORDER BY, I suppose you would need a wrapper. It's what
got me here in the first place; I was surprised how much difficulty this
user was having when attempting something rather
basic: https://stackoverflow.com/q/47716183/1163893. To come back to your
point, if the potential
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
>
> There's also the added burden on explaining that we can only pass one of
> the two kwargs, and not use both at the same time. I think that favors
> overloading a single kwarg.
>
I'm not clear *why* you wouldn't be able to use both at the same time? In
fact, this seems like the primary be
Sorry to resurrect this, but I commented on the bug tracker (
https://code.djangoproject.com/ticket/28839#comment:4 ) and was told to
take the discussion here.
I want to point out that __str__ is used for "GUI" purposes (such as
dropdown texts in ModelForm/ModelAdmin) and putting a default __st
Django has a number of optional features that require the installation of
additional Python packages.
Right now it's possible to $ pip install Django[bcrypt,argon2] to install
Django and the optional packages (at the correct minimum version) required
for bcrypt/argon2 support.
However this
10 matches
Mail list logo
