Reference GIS QuerySet API Reference Distance Lookups

Returns models where the distance to the geometry field from the lookup geometry is less than or equal to the given distance value.

Reference GIS QuerySet API Reference Distance Lookups

Returns models where the distance to the geometry field from the lookup geometry are within the given distance from one another. Note that you can only provide Distance objects if the targeted geometries are in a projected system.

Reference GIS QuerySet API Reference Distance Lookups

Django provides some GIS-specific aggregate functions. For details on how to use these aggregate functions, see the topic guide on aggregation.

Reference GIS QuerySet API Reference Distance LookupsAggregate Functions

classCollect(geo_field,filter=None)[source] Availability: PostGIS, MariaDB, MySQL, SpatiaLite Returns a GEOMETRYCOLLECTION or a MULTI geometry object from the geometry column.

Topic guide Aggregation Aggregations and other QuerySet clauses

Aggregates can also participate in filters. Any filter() (or exclude()) applied to normal model fields will have the effect of constraining the objects that are considered for aggregation.

Topic guide Aggregation Aggregations and other QuerySet clausesvalues()

As with the filter() clause, the order in which annotate() and values() clauses are applied to a query is significant. If the values() clause precedes the annotate(), the annotation will be computed using the grouping described by the values() clause.

Topic guide Aggregation Aggregations and other QuerySet clauses

You can also generate an aggregate on the result of an annotation. When you define an aggregate() clause, the aggregates you provide can reference any alias defined as part of an annotate() clause in the query.

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.