Release notes Django 1.11 release notes Backwards incompatible changes in 1.11

To prevent typos from passing silently, get_or_create() and update_or_create() check that their arguments are model fields. This should be backwards-incompatible only in the fact that it might expose a bug in your project.

Release notes Django 1.4 release notes What’s new in Django 1.4

Similar to select_related() but with a different strategy and broader scope, prefetch_related() has been added to QuerySet.

Release notes Django 1.6 release notes Backwards incompatible changes in 1.6Addition of QuerySet.datetimes()

QuerySet.dates() now returns a list of date. It used to return a list of datetime. QuerySet.datetimes() returns a list of datetime.

Release notes Django 1.6 release notes Backwards incompatible changes in 1.6Addition of QuerySet.datetimes()

QuerySet.dates() raises an error if it’s used on DateTimeField when time zone support is active. Use QuerySet.datetimes() instead.

Release notes Django 1.6 release notes Backwards incompatible changes in 1.6

The QuerySet iteration was changed to immediately convert all fetched rows to Model objects. In Django 1.5 and earlier the fetched rows were converted to Model objects in chunks of 100.

Release notes Django 2.0 release notes Backwards incompatible changes in 2.0

Calling QuerySet.reverse() or last() on a sliced queryset leads to unexpected results due to the slice being applied after reordering. This is now prohibited, e.g.:

Release notes Django 1.9 release notes Backwards incompatible changes in 1.9

In earlier versions, queries such as: would implicitly convert to: resulting in SQL like "related_id IN (SELECT id FROM ...)".

Release notes Django 1.6 release notes Backwards incompatible changes in 1.6

When the time zone support added in Django 1.4 was active, QuerySet.dates() lookups returned unexpected results, because the aggregation was performed in UTC. To fix this, Django 1.6 introduces a new API, QuerySet.datetimes().

Release notes Django 1.7 release notes What’s new in Django 1.7

The problem with this approach was that after the first method call, you’d get back a QuerySet instance and couldn’t call additional custom manager methods.

Release notes Django 1.7 release notes Features deprecated in 1.7

Callable arguments for querysets were an undocumented feature that was unreliable. It’s been deprecated and will be removed in Django 1.9.

Release notes Django 2.2.28 release notes

QuerySet.annotate(), aggregate(), and extra() methods were subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to these methods.

Release notes Django 2.2.28 release notes

QuerySet.explain() method was subject to SQL injection in option names, using a suitably crafted dictionary, with dictionary expansion, as the **options argument.

Release notes Django 3.2.13 release notes

QuerySet.annotate(), aggregate(), and extra() methods were subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to these methods.

Release notes Django 3.2.13 release notes

QuerySet.explain() method was subject to SQL injection in option names, using a suitably crafted dictionary, with dictionary expansion, as the **options argument.

Release notes Django 4.0.4 release notes

QuerySet.annotate(), aggregate(), and extra() methods were subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to these methods.

Release notes Django 4.0.4 release notes

QuerySet.explain() method was subject to SQL injection in option names, using a suitably crafted dictionary, with dictionary expansion, as the **options argument.

Release notes Django 4.2.15 release notes

QuerySet.values() and values_list() methods on models with a JSONField were subject to SQL injection in column aliases, via a crafted JSON object key as a passed *arg.

Release notes Django 4.2.25 release notes

QuerySet.annotate(), alias(), aggregate(), and extra() methods were subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to these methods (follow up to CVE 2022-28346).

Release notes Django 4.2.28 release notes

QuerySet.order_by() was subject to SQL injection in column aliases containing periods when the same alias was, using a suitably crafted dictionary, with dictionary expansion, used in FilteredRelation. This issue has severity “high” according to the Django security policy.

Release notes Django 5.0.8 release notes

QuerySet.values() and values_list() methods on models with a JSONField were subject to SQL injection in column aliases, via a crafted JSON object key as a passed *arg.