| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixed in f59fd15c4928caf3dfcbd50f6ab47be409a43b01
|
|
ForeignKey/OneToOneField
|
|
On sqlite the SUM() of a decimal column doesn't have a NUMERIC type so
when comparing it to a string literal (which a Decimal gets converted to
in Django) it is not compared as expected.
|
|
When the query's model had a self-referential foreign key, the
compiler.get_group_by() code incorrectly used the self-referential
foreign key's column (for example parent_id) as GROUP BY clause
when it should have used the model's primary key column (id).
|
|
|
|
The query used a construct of qs.annotate().values().aggregate() where
the first annotate used an F-object reference and the values() and
aggregate() calls referenced that F-object.
Also made sure the inner query's select clause is as simple as possible,
and made sure .values().distinct().aggreate() works correctly.
|
|
|
|
|
|
Thanks Anssi Kääriäinen, Marc Tamlyn, and Tim Graham for the reviews.
|
|
Refactored compiler SELECT, GROUP BY and ORDER BY generation.
While there, also refactored select_related() implementation
(get_cached_row() and get_klass_info() are now gone!).
Made get_db_converters() method work on expressions instead of
internal_type. This allows the backend converters to target
specific expressions if need be.
Added query.context, this can be used to set per-query state.
Also changed the signature of database converters. They now accept
context as an argument.
|
|
Aggregation over subquery produced syntactically incorrect queries in
some cases as Django didn't ensure that source expressions of the
aggregation were present in the subquery.
|
|
|
|
Thanks Loic Bistuer and Simon Charette for the review.
|
|
Complete rework of translating data values from database
Deprecation of SubfieldBase, removal of resolve_columns and
convert_values in favour of a more general converter based approach and
public API Field.from_db_value(). Now works seamlessly with aggregation,
.values() and raw queries.
Thanks to akaariai in particular for extensive advice and inspiration,
also to shaib, manfre and timograham for their reviews.
|
|
|
|
Thanks Piotr Kasprzyk for help with the patch.
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There were multiple cases where join promotion was a bit too aggressive.
This resulted in using outer joins where not necessary.
Refs #21150.
|
|
Added tests for a .annotate().select_related() join promotion failure.
This happened to work on master but was currently untested.
|
|
A .annotate().select_related() query resulted in misaligned rows vs
columns for compiler.resolve_columns() method.
Report & patch by Michael Manfre.
|
|
|
|
* override_settings may now be imported from django.test
* removed Approximate from django.test
* updated documentation for things importable from django.test
Thanks akaariai for the suggestion.
|
|
not have a default value
Thanks to Collin Anderson for the suggestion and Tim Graham for
reviewing the patch.
|
|
|
|
Should be unneeded with Python 2.7 and up.
Added some unicode_literals along the way.
|
|
Refs #20680.
|
|
The cause was assuming that an unordered queryset returns the values
always in the same order.
|
|
|
|
The sql/query.py add_q method did a lot of where/having tree hacking to
get complex queries to work correctly. The logic was refactored so that
it should be simpler to understand. The new logic should also produce
leaner WHERE conditions.
The changes cascade somewhat, as some other parts of Django (like
add_filter() and WhereNode) expect boolean trees in certain format or
they fail to work. So to fix the add_q() one must fix utils/tree.py,
some things in add_filter(), WhereNode and so on.
This commit also fixed add_filter to see negate clauses up the path.
A query like .exclude(Q(reversefk__in=a_list)) didn't work similarly to
.filter(~Q(reversefk__in=a_list)). The reason for this is that only
the immediate parent negate clauses were seen by add_filter, and thus a
tree like AND: (NOT AND: (AND: condition)) will not be handled
correctly, as there is one intermediary AND node in the tree. The
example tree is generated by .exclude(~Q(reversefk__in=a_list)).
Still, aggregation lost connectors in OR cases, and F() objects and
aggregates in same filter clause caused GROUP BY problems on some
databases.
Fixed #17600, fixed #13198, fixed #17025, fixed #17000, fixed #11293.
|
|
|
