Raising DatabaseError directly made it harder than it should to
differentiate between IntegrityError when a forced update resulted in no
affected rows.
Introducing a specialized exception allows for callers to more easily
silence, log, or turn them update failures into user facing exceptions
(e.g. 404s).
Thanks Mariusz for the review.
This moves the behaviors of `order_by` used in Postgres aggregates into
the `Aggregate` class. This allows for creating aggregate functions that
support this behavior across all database engines. This is shown by
moving the `StringAgg` class into the shared `aggregates` module and
adding support for all databases. The Postgres `StringAgg` class is now
a thin wrapper on the new shared `StringAgg` class.
Thank you Simon Charette for the review.
Thanks Lily Foote and Simon Charette for reviews and mentoring
this Google Summer of Code 2024 project.
Co-authored-by: Simon Charette <charette.s@gmail.com>
Co-authored-by: Lily Foote <code@lilyf.org>
Reorganized docs to list and explain the types of lazy relationships
that can be defined in related fields.
Co-authored-by: Natalia <124304+nessita@users.noreply.github.com>
Aggregation optimization didn't account for not referenced set-returning annotations on Postgres.
Co-authored-by: Simon Charette <charette.s@gmail.com>
Previously the order was always extra_fields + model_fields + annotations with
respective local ordering inferred from the insertion order of *selected.
This commits introduces a new `Query.selected` propery that keeps tracks of the
global select order as specified by on values assignment. This is crucial
feature to allow the combination of queries mixing annotations and table
references.
It also allows the removal of the re-ordering shenanigans perform by
ValuesListIterable in order to re-map the tuples returned from the database
backend to the order specified by values_list() as they'll be in the right
order at query compilation time.
Refs #28553 as the initially reported issue that was only partially fixed
for annotations by d6b6e5d0fd4e6b6d0183b4cf6e4bd4f9afc7bf67.
Thanks Mariusz Felisiak and Sarah Boyce for review.
This also introduces Expression.constraint_validation_compatible that
allows specifying that expression should be ignored during a constraint
validation.
Known issues have been fixed in:
- 0d8fbe2ade29f1b7bd9e6ba7a0281f5478603a43,
- c991602ce5798385261381025c06698d7fd30dc5, and
- 26aae5614487f58ddb1df5726224393887373ecd.