| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
self-referential subqueries if supported.
|
| |
|
|
|
|
|
|
| |
Black 23.1.0 is released which, as the first release of the year,
introduces the 2023 stable style. This incorporates most of last year's
preview style.
https://github.com/psf/black/releases/tag/23.1.0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
self-referential subqueries on MySQL.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Ticket19102Tests.test_ticket_19102_distinct_on.
The subquery pushdown only happens because another table is involved in
filter. It's not the distinct usage that causes the pushdown.
The distinct('description').order_by('pk') expression is not valid
because SELECT DISTINCT ON must match initial ORDER BY expressions
which is not the case here.
|
| | |
|
| | |
|
| |
|
|
| |
instance deletion.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This new technique is more straightforward and compatible with test
parallelization, where the effective database connection settings no
longer match settings.DATABASES.
|
| | |
|
| |
|
|
| |
ForeignKey/OneToOneField
|
| | |
|
| |
|
|
| |
Rewrote the test for #9479 according to the original ticket.
|
| | |
|
| |
|
|
|
|
|
| |
It contained models, forms and admin objects causing undesirable
import side effects. Refs #16368.
Thanks to Ramiro, Carl and Loïc for the review.
|
| |
|
|
| |
Signed-off-by: Jason Myers <jason@jasonamyers.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Should be unneeded with Python 2.7 and up.
Added some unicode_literals along the way.
|
| |
|
|
| |
Fixed #20483.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
enter_transaction_management() was nearly always followed by managed().
In three places it wasn't, but they will all be refactored eventually.
The "forced" keyword argument avoids introducing behavior changes until
then.
This is mostly backwards-compatible, except, of course, for managed
itself. There's a minor difference in _enter_transaction_management:
the top self.transaction_state now contains the new 'managed' state
rather than the previous one. Django doesn't access
self.transaction_state in _enter_transaction_management.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were a couple of errors in ._dirty flag handling:
* It started as None, but was never reset to None.
* The _dirty flag was sometimes used to indicate if the connection
was inside transaction management, but this was not done
consistently. This also meant the flag had three separate values.
* The None value had a special meaning, causing for example inability
to commit() on new connection unless enter/leave tx management was
done.
* The _dirty was tracking "connection in transaction" state, but only
in managed transactions.
* Some tests never reset the transaction state of the used connection.
* And some additional less important changes.
This commit has some potential for regressions, but as the above list
shows, the current situation isn't perfect either.
|
| |
|
