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 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.

Release notes Django 5.1.13 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 1.6 release notes Features deprecated in 1.6

Methods that return a QuerySet such as Manager.get_query_set or ModelAdmin.queryset have been renamed to get_queryset.

Release notes Django 3.1.13 release notes

Unsanitized user input passed to QuerySet.order_by() could bypass intended column reference validation in path marked for deprecation resulting in a potential SQL injection even if a deprecation warning is emitted.

Release notes Django 3.2.5 release notes

Unsanitized user input passed to QuerySet.order_by() could bypass intended column reference validation in path marked for deprecation resulting in a potential SQL injection even if a deprecation warning is emitted.

Release notes Django 5.0 release notes Backwards incompatible changes in 5.0

QuerySet.update_or_create() now supports the parameter create_defaults. As a consequence, any models that have a field named create_defaults that are used with an update_or_create() should specify the field in the lookup with create_defaults__exact.