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.
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 1cd6e04cd4
given no regression tests fail when m2m_changed is not taken into
consideration to determine if fast-delete can be enabled.
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.
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.
Field.rel is now deprecated. Rel objects have now also remote_field
attribute. This means that self == self.remote_field.remote_field.
In addition, made the Rel objects a bit more like Field objects. Still,
marked ManyToManyFields as null=True.
SQLite doesn't work with more than 1000 parameters in a single query.
The deletion code could generate queries that try to get related
objects for more than 1000 objects thus breaking the limit. Django now
splits the related object fetching into batches with at most 1000
parameters.
The tests and patch include some work done by Trac alias NiGhTTraX in
ticket #21205.
Matthias Kestenholz
Hasan Ramezani
Mariusz Felisiak
Daniel Izquierdo
Simon Charette
Stephen Brown
Simon Charette
Florian Apolloner
Nick Pope
Étienne Loks
Дилян Палаузов
Tim Graham
Anton Samarchyan
chillaranand
Simon Charette
Claude Paroz
Michal Petrucha
Laura Feier
sarthakmeh
Maxime Lorant
Alexander Sosnovskiy
Anssi Kääriäinen
Andriy Sokolovskiy
Loic Bistuer
Daniel Pyrathon
Thomas Chaumeny
Anssi Kääriäinen
Gavin Wahl
Aymeric Augustin
Rodolfo Carvalho
Christopher Medrela
Loic Bistuer
Curtis Maloney