| Age | Commit message (Collapse) | Author |
|---|
|
Thanks Simon Charette for pair programming.
Co-authored-by: Nick Stefan <NickStefan12@gmail.com>
Co-authored-by: Akash Kumar Sen <71623442+Akash-Kumar-Sen@users.noreply.github.com>
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
when keep_parents=True.
Signed-off-by: saJaeHyukc <wogur981208@gmail.com>
|
|
Rewrapped long docstrings and block comments to 79 characters + newline
using script from https://github.com/medmunds/autofix-w505.
|
|
|
|
max_batch_size.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
co-authored-by: Keryn Knight <keryn@kerynknight.com>
co-authored-by: Natalia <124304+nessita@users.noreply.github.com>
co-authored-by: David Smith <smithdc@gmail.com>
co-authored-by: Paolo Melchiorre <paolo@melchiorre.org>
|
|
SET/SET_DEFAULT in Collector.collect().
|
|
Models that use SET, SET_NULL, and SET_DEFAULT as on_delete handler
don't have to fetch objects for the sole purpose of passing them back to
a follow up UPDATE query filtered by the retrieved objects primary key.
This was achieved by flagging SET handlers as _lazy_ and having the
collector logic defer object collections until the last minute. This
should ensure that the rare cases where custom on_delete handlers are
defined remain uncalled when when dealing with an empty collection of
instances.
This reduces the number queries required to apply SET handlers from
2 to 1 where the remaining UPDATE use the same predicate as the non
removed SELECT query.
In a lot of ways this is similar to the fast-delete optimization that
was added in #18676 but for updates this time. The conditions only
happen to be simpler in this case because SET handlers are always
terminal. They never cascade to more deletes that can be combined.
Thanks Renan GEHAN for the report.
|
|
Model instances retrieved for bulk field update purposes are not exposed
to the outside world and thus are not required to be kept update to
date.
|
|
Node.create() which has a compatible signature with Node.__init__()
takes in a single `children` argument rather than relying in unpacking
*args in Q.__init__() which calls Node.__init__().
In addition, we were often needing to unpack iterables into *args and
can instead pass a list direct to Node.create().
|
|
|
|
|
|
use non-kwargs initialization.
This prefers non-kwargs construction of dynamically generated Q()
objects to create a single Q() object instead of many and then
combining them, where possible.
|
|
RestrictedError.restricted_objects.
Regression in 4ca5c565f4dc9e97845036e86416abc5cfde766c and
ab3cbd8b9a315911248227208630a020cedca08f.
Thanks Vitaliy Yelnik for the report.
|
|
Regression in c7dd8490b882b2cefdc7faf431dc64c532b79c9.
|
|
objects if it's zero.
|
|
objects.
|
|
rather than just the first one.
|
|
redefinition.
|
|
rather than just the first one.
Thanks Anton Samarchyan for the initial patch.
|
|
deletions while protecting direct ones.
|
|
|
|
Reduced the number of queries required when performing cascade deletion
for a model referenced multiple time by another one by performing an
union of reference lookups.
|
|
|
|
|
|
reverse relationships.
Thanks Simon Charette for the review.
|
|
The non-referenced fields can only be deferred if no deletion signals
receivers are connected for their respective model as connected as these
receivers might expect all fields of the deleted model to be present.
Thanks Ed Morley for the report.
|
|
There's no reason to disable fast-delete when an intermediary
many-to-many model has connected m2m_changed receivers because the
signal is only sent when related manager's clear() and remove() methods
are directly called.
This must have been overlooked in 1cd6e04cd4f768bcd4385b75de433d497d938f82
given no regression tests fail when m2m_changed is not taken into
consideration to determine if fast-delete can be enabled.
|
|
Regression in bc7dd8490b882b2cefdc7faf431dc64c532b79c9.
|
|
Dicts preserve order since Python 3.6.
|
|
queries) are executed.
Checked the following locations:
* Model.save(): If there are parents involved, take the safe way and use
transactions since this should be an all or nothing operation.
If the model has no parents:
* Signals are executed before and after the previous existing
transaction -- they were never been part of the transaction.
* if `force_insert` is set then only one query is executed -> atomic
by definition and no transaction needed.
* same applies to `force_update`.
* If a primary key is set and no `force_*` is set Django will try an
UPDATE and if that returns zero rows it tries an INSERT. The first
case is completly save (single query). In the second case a
transaction should not produce different results since the update
query is basically a no-op then (might miss something though).
* QuerySet.update(): no signals issued, single query -> no transaction
needed.
* Model/Collector.delete(): This one is fun due to the fact that is
does many things at once.
Most importantly though: It does send signals as part of the
transaction, so for maximum backwards compatibility we need to be
conservative.
To ensure maximum compatibility the transaction here is removed only
if the following holds true:
* A single instance is being deleted.
* There are no signal handlers attached to that instance.
* There are no deletions/updates to cascade.
* There are no parents which also need deletion.
|
|
instance deletion.
|
|
|
|
|
|
|
|
|
|
|
|
Thanks Tim Graham for the review.
|
|
relationships.
Thanks Tim for the review.
|
|
|
|
The only reason why GenericForeignKey and GenericRelation are stored
separately inside _meta is that they need to be cloned for every model
subclass, but that's not true for any other virtual field. Actually,
it's only true for GenericRelation.
|
|
|
|
|
|
|
|
Prior to this change proxy models reverse fields didn't include the
reverse fields pointing to their concrete model.
|
|
Thanks to James Murty for his work on an alternate patch.
|
|
This isn't required anymore now that reverse foreign keys
from proxy models are propagated to their concrete model.
|
|
admin's delete confirmation page.
|
|
|
|
objects.
|
