Query expressions describe a value or a computation that can be used as part of\nan update, create, filter, order by, annotation, or aggregate. When an\nexpression outputs a boolean value, it may be used directly in filters. There\nare a number of built-in expressions (documented below) that can be used to\nhelp you write queries. Expressions can be combined, or in some cases nested,\nto form more complex computations.
\nDjango supports negation, addition, subtraction, multiplication, division,\nmodulo arithmetic, and the power operator on query expressions, using Python\nconstants, variables, and even other expressions.
\nMany of the expressions documented in this section support an optional\noutput_field parameter. If given, Django will load the value into that\nfield after retrieving it from the database.
output_field takes a model field instance, like IntegerField() or\nBooleanField(). Usually, the field doesn’t need any arguments, like\nmax_length, since field arguments relate to data validation which will not\nbe performed on the expression’s output value.
output_field is only required when Django is unable to automatically\ndetermine the result’s field type, such as complex expressions that mix field\ntypes. For example, adding a DecimalField() and a FloatField() requires\nan output field, like output_field=FloatField().
>>> from django.db.models import Count, F, Value\n>>> from django.db.models.functions import Length, Upper\n>>> from django.db.models.lookups import GreaterThan\n\n# Find companies that have more employees than chairs.\n>>> Company.objects.filter(num_employees__gt=F("num_chairs"))\n\n# Find companies that have at least twice as many employees\n# as chairs. Both the querysets below are equivalent.\n>>> Company.objects.filter(num_employees__gt=F("num_chairs") * 2)\n>>> Company.objects.filter(num_employees__gt=F("num_chairs") + F("num_chairs"))\n\n# How many chairs are needed for each company to seat all employees?\n>>> company = (\n... Company.objects.filter(num_employees__gt=F("num_chairs"))\n... .annotate(chairs_needed=F("num_employees") - F("num_chairs"))\n... .first()\n... )\n>>> company.num_employees\n120\n>>> company.num_chairs\n50\n>>> company.chairs_needed\n70\n\n# Create a new company using expressions.\n>>> company = Company.objects.create(name="Google", ticker=Upper(Value("goog")))\n# Be sure to refresh it if you need to access the field.\n>>> company.refresh_from_db()\n>>> company.ticker\n'GOOG'\n\n# Annotate models with an aggregated value. Both forms\n# below are equivalent.\n>>> Company.objects.annotate(num_products=Count("products"))\n>>> Company.objects.annotate(num_products=Count(F("products")))\n\n# Aggregates can contain complex computations also\n>>> Company.objects.annotate(num_offerings=Count(F("products") + F("services")))\n\n# Expressions can also be used in order_by(), either directly\n>>> Company.objects.order_by(Length("name").asc())\n>>> Company.objects.order_by(Length("name").desc())\n# or using the double underscore lookup syntax.\n>>> from django.db.models import CharField\n>>> from django.db.models.functions import Length\n>>> CharField.register_lookup(Length)\n>>> Company.objects.order_by("name__length")\n\n# Boolean expression can be used directly in filters.\n>>> from django.db.models import Exists, OuterRef\n>>> Company.objects.filter(\n... Exists(Employee.objects.filter(company=OuterRef("pk"), salary__gt=10))\n... )\n\n# Lookup expressions can also be used directly in filters\n>>> Company.objects.filter(GreaterThan(F("num_employees"), F("num_chairs")))\n# or annotations.\n>>> Company.objects.annotate(\n... need_chairs=GreaterThan(F("num_employees"), F("num_chairs")),\n... )\nF() expressionsLink to this heading#An F() object represents the value of a model field, transformed value of a\nmodel field, or annotated column. It makes it possible to refer to model field\nvalues and perform database operations using them without actually having to\npull them out of the database into Python memory.
Instead, Django uses the F() object to generate an SQL expression that\ndescribes the required operation at the database level.
Let’s try this with an example. Normally, one might do something like this:
\n# Tintin filed a news story!\nreporter = Reporters.objects.get(name="Tintin")\nreporter.stories_filed += 1\nreporter.save()\nHere, we have pulled the value of reporter.stories_filed from the database\ninto memory and manipulated it using familiar Python operators, and then saved\nthe object back to the database. But instead we could also have done:
from django.db.models import F\n\nreporter = Reporters.objects.get(name="Tintin")\nreporter.stories_filed = F("stories_filed") + 1\nreporter.save()\nAlthough reporter.stories_filed = F('stories_filed') + 1 looks like a\nnormal Python assignment of value to an instance attribute, in fact it’s an SQL\nconstruct describing an operation on the database.
When Django encounters an instance of F(), it overrides the standard Python\noperators to create an encapsulated SQL expression; in this case, one which\ninstructs the database to increment the database field represented by\nreporter.stories_filed.
Whatever value is or was on reporter.stories_filed, Python never gets to\nknow about it - it is dealt with entirely by the database. All Python does,\nthrough Django’s F() class, is create the SQL syntax to refer to the field\nand describe the operation.
To access the new value saved this way, the object must be reloaded:
\nreporter = Reporters.objects.get(pk=reporter.pk)\n# Or, more succinctly:\nreporter.refresh_from_db()\nAs well as being used in operations on single instances as above, F() can\nbe used on QuerySets of object instances, with update(). This reduces\nthe two queries we were using above - the get() and the\nsave() - to just one:
reporter = Reporters.objects.filter(name="Tintin")\nreporter.update(stories_filed=F("stories_filed") + 1)\nWe can also use update() to increment\nthe field value on multiple objects - which could be very much faster than\npulling them all into Python from the database, looping over them, incrementing\nthe field value of each one, and saving each one back to the database:
Reporter.objects.update(stories_filed=F("stories_filed") + 1)\nF() therefore can offer performance advantages by:
getting the database, rather than Python, to do work
reducing the number of queries some operations require
F()Link to this heading#Another useful benefit of F() is that having the database - rather than\nPython - update a field’s value avoids a race condition.
If two Python threads execute the code in the first example above, one thread\ncould retrieve, increment, and save a field’s value after the other has\nretrieved it from the database. The value that the second thread saves will be\nbased on the original value; the work of the first thread will be lost.
\nIf the database is responsible for updating the field, the process is more\nrobust: it will only ever update the field based on the value of the field in\nthe database when the save() or update() is executed, rather\nthan based on its value when the instance was retrieved.
F() assignments persist after Model.save()Link to this heading#F() objects assigned to model fields persist after saving the model\ninstance and will be applied on each save(). For example:
reporter = Reporters.objects.get(name="Tintin")\nreporter.stories_filed = F("stories_filed") + 1\nreporter.save()\n\nreporter.name = "Tintin Jr."\nreporter.save()\nstories_filed will be updated twice in this case. If it’s initially 1,\nthe final value will be 3. This persistence can be avoided by reloading the\nmodel object after saving it, for example, by using\nrefresh_from_db().
F() in filtersLink to this heading#F() is also very useful in QuerySet filters, where they make it\npossible to filter a set of objects against criteria based on their field\nvalues, rather than on Python values.
This is documented in using F() expressions in queries.
\nF() with annotationsLink to this heading#F() can be used to create dynamic fields on your models by combining\ndifferent fields with arithmetic:
company = Company.objects.annotate(chairs_needed=F("num_employees") - F("num_chairs"))\nIf the fields that you’re combining are of different types you’ll need to tell\nDjango what kind of field will be returned. Most expressions support\noutput_field for this case, but since F() does not, you\nwill need to wrap the expression with ExpressionWrapper:
from django.db.models import DateTimeField, ExpressionWrapper, F\n\nTicket.objects.annotate(\n expires=ExpressionWrapper(\n F("active_at") + F("duration"), output_field=DateTimeField()\n )\n)\nWhen referencing relational fields such as ForeignKey, F() returns the\nprimary key value rather than a model instance:
>>> car = Company.objects.annotate(built_by=F("manufacturer"))[0]\n>>> car.manufacturer\n<Manufacturer: Toyota>\n>>> car.built_by\n3\nF() to sort null valuesLink to this heading#Use F() and the nulls_first or nulls_last keyword argument to\nExpression.asc() or desc() to control the ordering of\na field’s null values. By default, the ordering depends on your database.
For example, to sort companies that haven’t been contacted (last_contacted\nis null) after companies that have been contacted:
from django.db.models import F\n\nCompany.objects.order_by(F("last_contacted").desc(nulls_last=True))\nF() with logical operationsLink to this heading#F() expressions that output BooleanField can be logically negated with\nthe inversion operator ~F(). For example, to swap the activation status of\ncompanies:
from django.db.models import F\n\nCompany.objects.update(is_active=~F("is_active"))\nFunc() expressionsLink to this heading#Func() expressions are the base type of all expressions that involve\ndatabase functions like COALESCE and LOWER, or aggregates like SUM.\nThey can be used directly:
from django.db.models import F, Func\n\nqueryset.annotate(field_lower=Func(F("field"), function="LOWER"))\nor they can be used to build a library of database functions:
\nclass Lower(Func):\n function = "LOWER"\n\n\nqueryset.annotate(field_lower=Lower("field"))\nBut both cases will result in a queryset where each model is annotated with an\nextra attribute field_lower produced, roughly, from the following SQL:
SELECT\n ...\n LOWER("db_table"."field") as "field_lower"\nSee Database Functions for a list of built-in database functions.
\nThe Func API is as follows:
A class attribute describing the function that will be generated.\nSpecifically, the function will be interpolated as the function\nplaceholder within template. Defaults to None.
A class attribute, as a format string, that describes the SQL that is\ngenerated for this function. Defaults to\n'%(function)s(%(expressions)s)'.
If you’re constructing SQL like strftime('%W', 'date') and need a\nliteral % character in the query, quadruple it (%%%%) in the\ntemplate attribute because the string is interpolated twice: once\nduring the template interpolation in as_sql() and once in the SQL\ninterpolation with the query parameters in the database cursor.
A class attribute that denotes the character used to join the list of\nexpressions together. Defaults to ', '.
A class attribute that denotes the number of arguments the function\naccepts. If this attribute is set and the function is called with a\ndifferent number of expressions, TypeError will be raised. Defaults\nto None.
Generates the SQL fragment for the database function. Returns a tuple\n(sql, params), where sql is the SQL string, and params is\nthe list or tuple of query parameters.
The as_vendor() methods should use the function, template,\narg_joiner, and any other **extra_context parameters to\ncustomize the SQL as needed. For example:
django/db/models/functions.pyclass ConcatPair(Func):\n ...\n function = "CONCAT"\n ...\n\n def as_mysql(self, compiler, connection, **extra_context):\n return super().as_sql(\n compiler,\n connection,\n function="CONCAT_WS",\n template="%(function)s('', %(expressions)s)",\n **extra_context\n )\nTo avoid an SQL injection vulnerability, extra_context must\nnot contain untrusted user input\nas these values are interpolated into the SQL string rather than passed\nas query parameters, where the database driver would escape them.
The *expressions argument is a list of positional expressions that the\nfunction will be applied to. The expressions will be converted to strings,\njoined together with arg_joiner, and then interpolated into the template\nas the expressions placeholder.
Positional arguments can be expressions or Python values. Strings are\nassumed to be column references and will be wrapped in F() expressions\nwhile other values will be wrapped in Value() expressions.
The **extra kwargs are key=value pairs that can be interpolated\ninto the template attribute. To avoid an SQL injection vulnerability,\nextra must not contain untrusted user input as these values are interpolated\ninto the SQL string rather than passed as query parameters, where the database\ndriver would escape them.
The function, template, and arg_joiner keywords can be used to\nreplace the attributes of the same name without having to define your own\nclass. output_field can be used to define the expected\nreturn type.
Aggregate() expressionsLink to this heading#An aggregate expression is a special case of a Func() expression that informs the query that a GROUP BY clause\nis required. All of the aggregate functions,\nlike Sum() and Count(), inherit from Aggregate().
Since Aggregates are expressions and wrap expressions, you can represent\nsome complex computations:
from django.db.models import Count\n\nCompany.objects.annotate(\n managers_required=(Count("num_employees") / 4) + Count("num_managers")\n)\nThe Aggregate API is as follows:
A class attribute, as a format string, that describes the SQL that is\ngenerated for this aggregate. Defaults to\n'%(function)s(%(distinct)s%(expressions)s)'.
A class attribute describing the aggregate function that will be\ngenerated. Specifically, the function will be interpolated as the\nfunction placeholder within template. Defaults to None.
Defaults to True since most aggregate functions can be used as the\nsource expression in Window.
A class attribute determining whether or not this aggregate function\nallows passing a distinct keyword argument. If set to False\n(default), TypeError is raised if distinct=True is passed.
Defaults to None since most aggregate functions result in NULL\nwhen applied to an empty result set.
The expressions positional arguments can include expressions, transforms of\nthe model field, or the names of model fields. They will be converted to a\nstring and used as the expressions placeholder within the template.
The distinct argument determines whether or not the aggregate function\nshould be invoked for each distinct value of expressions (or set of\nvalues, for multiple expressions). The argument is only supported on\naggregates that have allow_distinct set to True.
The filter argument takes a Q object that’s\nused to filter the rows that are aggregated. See Conditional aggregation\nand Filtering on annotations for example usage.
The default argument takes a value that will be passed along with the\naggregate to Coalesce. This is useful for\nspecifying a value to be returned other than None when the queryset (or\ngrouping) contains no entries.
The **extra kwargs are key=value pairs that can be interpolated\ninto the template attribute.
You can create your own aggregate functions, too. At a minimum, you need to\ndefine function, but you can also completely customize the SQL that is\ngenerated. Here’s a brief example:
from django.db.models import Aggregate\n\n\nclass Sum(Aggregate):\n # Supports SUM(ALL field).\n function = "SUM"\n template = "%(function)s(%(all_values)s%(expressions)s)"\n allow_distinct = False\n\n def __init__(self, expression, all_values=False, **extra):\n super().__init__(expression, all_values="ALL " if all_values else "", **extra)\nValue() expressionsLink to this heading#A Value() object represents the smallest possible component of an\nexpression: a simple value. When you need to represent the value of an integer,\nboolean, or string within an expression, you can wrap that value within a\nValue().
You will rarely need to use Value() directly. When you write the expression\nF('field') + 1, Django implicitly wraps the 1 in a Value(),\nallowing simple values to be used in more complex expressions. You will need to\nuse Value() when you want to pass a string to an expression. Most\nexpressions interpret a string argument as the name of a field, like\nLower('name').
The value argument describes the value to be included in the expression,\nsuch as 1, True, or None. Django knows how to convert these Python\nvalues into their corresponding database type.
If no output_field is specified, it will be inferred from\nthe type of the provided value for many common types. For example, passing\nan instance of datetime.datetime as value defaults\noutput_field to DateTimeField.
ExpressionWrapper() expressionsLink to this heading#ExpressionWrapper surrounds another expression and provides access to\nproperties, such as output_field, that may not be\navailable on other expressions. ExpressionWrapper is necessary when using\narithmetic on F() expressions with different types as described in\nUsing F() with annotations.
Conditional expressions allow you to use if … elif …\nelse logic in queries. Django natively supports SQL CASE\nexpressions. For more details see Conditional Expressions.
Subquery() expressionsLink to this heading#You can add an explicit subquery to a QuerySet using the Subquery\nexpression.
For example, to annotate each post with the email address of the author of the\nnewest comment on that post:
\n>>> from django.db.models import OuterRef, Subquery\n>>> newest = Comment.objects.filter(post=OuterRef("pk")).order_by("-created_at")\n>>> Post.objects.annotate(newest_commenter_email=Subquery(newest.values("email")[:1]))\nOn PostgreSQL, the SQL looks like:
\nSELECT "post"."id", (\n SELECT U0."email"\n FROM "comment" U0\n WHERE U0."post_id" = ("post"."id")\n ORDER BY U0."created_at" DESC LIMIT 1\n) AS "newest_commenter_email" FROM "post"\nUse OuterRef when a queryset in a Subquery needs to refer to a field\nfrom the outer query or its transform. It acts like an F expression\nexcept that the check to see if it refers to a valid field isn’t made until the\nouter queryset is resolved.
Instances of OuterRef may be used in conjunction with nested instances\nof Subquery to refer to a containing queryset that isn’t the immediate\nparent. For example, this queryset would need to be within a nested pair of\nSubquery instances to resolve correctly:
>>> Book.objects.filter(author=OuterRef(OuterRef("pk")))\nThere are times when a single column must be returned from a Subquery, for\ninstance, to use a Subquery as the target of an __in lookup. To return\nall comments for posts published within the last day:
>>> from datetime import timedelta\n>>> from django.utils import timezone\n>>> one_day_ago = timezone.now() - timedelta(days=1)\n>>> posts = Post.objects.filter(published_at__gte=one_day_ago)\n>>> Comment.objects.filter(post__in=Subquery(posts.values("pk")))\nIn this case, the subquery must use values()\nto return only a single column: the primary key of the post.
To prevent a subquery from returning multiple rows, a slice ([:1]) of the\nqueryset is used:
>>> subquery = Subquery(newest.values("email")[:1])\n>>> Post.objects.annotate(newest_commenter_email=subquery)\nIn this case, the subquery must only return a single column and a single\nrow: the email address of the most recently created comment.
\n(Using get() instead of a slice would fail because the\nOuterRef cannot be resolved until the queryset is used within a\nSubquery.)
Exists() subqueriesLink to this heading#Exists is a Subquery subclass that uses an SQL EXISTS statement. In\nmany cases it will perform better than a subquery since the database is able to\nstop evaluation of the subquery when a first matching row is found.
For example, to annotate each post with whether or not it has a comment from\nwithin the last day:
\n>>> from django.db.models import Exists, OuterRef\n>>> from datetime import timedelta\n>>> from django.utils import timezone\n>>> one_day_ago = timezone.now() - timedelta(days=1)\n>>> recent_comments = Comment.objects.filter(\n... post=OuterRef("pk"),\n... created_at__gte=one_day_ago,\n... )\n>>> Post.objects.annotate(recent_comment=Exists(recent_comments))\nOn PostgreSQL, the SQL looks like:
\nSELECT "post"."id", "post"."published_at", EXISTS(\n SELECT (1) as "a"\n FROM "comment" U0\n WHERE (\n U0."created_at" >= YYYY-MM-DD HH:MM:SS AND\n U0."post_id" = "post"."id"\n )\n LIMIT 1\n) AS "recent_comment" FROM "post"\nIt’s unnecessary to force Exists to refer to a single column, since the\ncolumns are discarded and a boolean result is returned. Similarly, since\nordering is unimportant within an SQL EXISTS subquery and would only\ndegrade performance, it’s automatically removed.
You can query using NOT EXISTS with ~Exists().
Subquery() or Exists() expressionsLink to this heading#Subquery() that returns a boolean value and Exists() may be used as a\ncondition in When expressions, or to\ndirectly filter a queryset:
>>> recent_comments = Comment.objects.filter(...) # From above\n>>> Post.objects.filter(Exists(recent_comments))\nThis will ensure that the subquery will not be added to the SELECT columns,\nwhich may result in a better performance.
Subquery expressionLink to this heading#Aggregates may be used within a Subquery, but they require a specific\ncombination of filter(), values(), and\nannotate() to get the subquery grouping correct.
Assuming both models have a length field, to find posts where the post\nlength is greater than the total length of all combined comments:
>>> from django.db.models import OuterRef, Subquery, Sum\n>>> comments = Comment.objects.filter(post=OuterRef("pk")).order_by().values("post")\n>>> total_comments = comments.annotate(total=Sum("length")).values("total")\n>>> Post.objects.filter(length__gt=Subquery(total_comments))\nThe initial filter(...) limits the subquery to the relevant parameters.\norder_by() removes the default ordering\n(if any) on the Comment model. values('post') aggregates comments by\nPost. Finally, annotate(...) performs the aggregation. The order in\nwhich these queryset methods are applied is important. In this case, since the\nsubquery must be limited to a single column, values('total') is required.
This is the only way to perform an aggregation within a Subquery, as\nusing aggregate() attempts to evaluate the queryset (and if\nthere is an OuterRef, this will not be possible to resolve).
Sometimes database expressions can’t easily express a complex WHERE clause.\nIn these edge cases, use the RawSQL expression. For example:
>>> from django.db.models.expressions import RawSQL\n>>> queryset.annotate(val=RawSQL("select col from sometable where othercol = %s", (param,)))\nThese extra lookups may not be portable to different database engines (because\nyou’re explicitly writing SQL code) and violate the DRY principle, so you\nshould avoid them if possible.
\nRawSQL expressions can also be used as the target of __in filters:
>>> queryset.filter(id__in=RawSQL("select id from sometable where col = %s", (param,)))\nWindow functions provide a way to apply functions on partitions. Unlike a\nnormal aggregation function which computes a final result for each set defined\nby the group by, window functions operate on frames and\npartitions, and compute the result for each row.
\nYou can specify multiple windows in the same query which in Django ORM would be\nequivalent to including multiple expressions in a QuerySet.annotate() call. The ORM doesn’t make use of named windows,\ninstead they are part of the selected columns.
\nDefaults to %(expression)s OVER (%(window)s). If only the\nexpression argument is provided, the window clause will be blank.
The Window class is the main expression for an OVER clause.
The expression argument is either a window function, an aggregate function, or\nan expression that’s compatible in a window clause.
The partition_by argument accepts an expression or a sequence of\nexpressions (column names should be wrapped in an F-object) that control\nthe partitioning of the rows. Partitioning narrows which rows are used to\ncompute the result set.
The output_field is specified either as an argument or by\nthe expression.
\nThe order_by argument accepts an expression on which you can call\nasc() and\ndesc(), a string of a field name (with an\noptional "-" prefix which indicates descending order), or a tuple or list\nof strings and/or expressions. The ordering controls the order in which the\nexpression is applied. For example, if you sum over the rows in a partition,\nthe first result is the value of the first row, the second is the sum of first\nand second row.
The frame parameter specifies which other rows that should be used in the\ncomputation. See Frames for details.
For example, to annotate each movie with the average rating for the movies by\nthe same studio in the same genre and release year:
\n>>> from django.db.models import Avg, F, Window\n>>> Movie.objects.annotate(\n... avg_rating=Window(\n... expression=Avg("rating"),\n... partition_by=[F("studio"), F("genre")],\n... order_by="released__year",\n... ),\n... )\nThis allows you to check if a movie is rated better or worse than its peers.
\nYou may want to apply multiple expressions over the same window, i.e., the\nsame partition and frame. For example, you could modify the previous example\nto also include the best and worst rating in each movie’s group (same studio,\ngenre, and release year) by using three window functions in the same query. The\npartition and ordering from the previous example is extracted into a dictionary\nto reduce repetition:
\n>>> from django.db.models import Avg, F, Max, Min, Window\n>>> window = {\n... "partition_by": [F("studio"), F("genre")],\n... "order_by": "released__year",\n... }\n>>> Movie.objects.annotate(\n... avg_rating=Window(\n... expression=Avg("rating"),\n... **window,\n... ),\n... best=Window(\n... expression=Max("rating"),\n... **window,\n... ),\n... worst=Window(\n... expression=Min("rating"),\n... **window,\n... ),\n... )\nFiltering against window functions is supported as long as lookups are not\ndisjunctive (not using OR or XOR as a connector) and against a queryset\nperforming aggregation.
For example, a query that relies on aggregation and has an OR-ed filter\nagainst a window function and a field is not supported. Applying combined\npredicates post-aggregation could cause rows that would normally be excluded\nfrom groups to be included:
>>> qs = Movie.objects.annotate(\n... category_rank=Window(Rank(), partition_by="category", order_by="-rating"),\n... scenes_count=Count("actors"),\n... ).filter(Q(category_rank__lte=3) | Q(title__contains="Batman"))\n>>> list(qs)\nNotImplementedError: Heterogeneous disjunctive predicates against window functions\nare not implemented when performing conditional aggregation.\nAmong Django’s built-in database backends, MySQL, PostgreSQL, and Oracle\nsupport window expressions. Support for different window expression features\nvaries among the different databases. For example, the options in\nasc() and\ndesc() may not be supported. Consult the\ndocumentation for your database as needed.
For a window frame, you can choose either a range-based sequence of rows or an\nordinary sequence of rows.
\nThis attribute is set to 'RANGE'.
PostgreSQL has limited support for ValueRange and only supports use of\nthe standard start and end points, such as CURRENT ROW and UNBOUNDED\nFOLLOWING.
This attribute is set to 'ROWS'.
Both classes return SQL with the template:
\n%(frame_type)s BETWEEN %(start)s AND %(end)s\nFrames narrow the rows that are used for computing the result. They shift from\nsome start point to some specified end point. Frames can be used with and\nwithout partitions, but it’s often a good idea to specify an ordering of the\nwindow to ensure a deterministic result. In a frame, a peer in a frame is a row\nwith an equivalent value, or all rows if an ordering clause isn’t present.
\nThe default starting point for a frame is UNBOUNDED PRECEDING which is the\nfirst row of the partition. The end point is always explicitly included in the\nSQL generated by the ORM and is by default UNBOUNDED FOLLOWING. The default\nframe includes all rows from the partition to the last row in the set.
The accepted values for the start and end arguments are None, an\ninteger, or zero. A negative integer for start results in N preceding,\nwhile None yields UNBOUNDED PRECEDING. For both start and end,\nzero will return CURRENT ROW. Positive integers are accepted for end.
There’s a difference in what CURRENT ROW includes. When specified in\nROWS mode, the frame starts or ends with the current row. When specified in\nRANGE mode, the frame starts or ends at the first or last peer according to\nthe ordering clause. Thus, RANGE CURRENT ROW evaluates the expression for\nrows which have the same value specified by the ordering. Because the template\nincludes both the start and end points, this may be expressed with:
ValueRange(start=0, end=0)\nIf a movie’s „peers” are described as movies released by the same studio in the\nsame genre in the same year, this RowRange example annotates each movie\nwith the average rating of a movie’s two prior and two following peers:
>>> from django.db.models import Avg, F, RowRange, Window\n>>> Movie.objects.annotate(\n... avg_rating=Window(\n... expression=Avg("rating"),\n... partition_by=[F("studio"), F("genre")],\n... order_by="released__year",\n... frame=RowRange(start=-2, end=2),\n... ),\n... )\nIf the database supports it, you can specify the start and end points based on\nvalues of an expression in the partition. If the released field of the\nMovie model stores the release month of each movie, this ValueRange\nexample annotates each movie with the average rating of a movie’s peers\nreleased between twelve months before and twelve months after each movie:
>>> from django.db.models import Avg, F, ValueRange, Window\n>>> Movie.objects.annotate(\n... avg_rating=Window(\n... expression=Avg("rating"),\n... partition_by=[F("studio"), F("genre")],\n... order_by="released__year",\n... frame=ValueRange(start=-12, end=12),\n... ),\n... )\nBelow you’ll find technical implementation details that may be useful to\nlibrary authors. The technical API and examples below will help with\ncreating generic query expressions that can extend the built-in functionality\nthat Django provides.
\nQuery expressions implement the query expression API,\nbut also expose a number of extra methods and attributes listed below. All\nquery expressions must inherit from Expression() or a relevant\nsubclass.
When a query expression wraps another expression, it is responsible for\ncalling the appropriate methods on the wrapped expression.
\nTells Django that this expression can be used in\nField.db_default. Defaults to False.
Tells Django that this expression contains an aggregate and that a\nGROUP BY clause needs to be added to the query.
Tells Django that this expression contains a\nWindow expression. It’s used,\nfor example, to disallow window function expressions in queries that\nmodify data.
Tells Django that this expression can be referenced in\nQuerySet.filter(). Defaults to True.
Tells Django that this expression can be used as the source expression\nin Window. Defaults to\nFalse.
Tells Django which value should be returned when the expression is used\nto apply a function over an empty result set. Defaults to\nNotImplemented which forces the expression to be computed on\nthe database.
Provides the chance to do any preprocessing or validation of\nthe expression before it’s added to the query. resolve_expression()\nmust also be called on any nested expressions. A copy() of self\nshould be returned with any necessary transformations.
query is the backend query implementation.
allow_joins is a boolean that allows or denies the use of\njoins in the query.
reuse is a set of reusable joins for multi-join scenarios.
summarize is a boolean that, when True, signals that the\nquery being computed is a terminal aggregate query.
for_save is a boolean that, when True, signals that the query\nbeing executed is performing a create or update.
Returns an ordered list of inner expressions. For example:
\n>>> Sum(F("foo")).get_source_expressions()\n[F('foo')]\nTakes a list of expressions and stores them such that\nget_source_expressions() can return them.
Returns a clone (copy) of self, with any column aliases relabeled.\nColumn aliases are renamed when subqueries are created.\nrelabeled_clone() should also be called on any nested expressions\nand assigned to the clone.
change_map is a dictionary mapping old aliases to new aliases.
Example:
\ndef relabeled_clone(self, change_map):\n clone = copy.copy(self)\n clone.expression = self.expression.relabeled_clone(change_map)\n return clone\nA hook allowing the expression to coerce value into a more\nappropriate type.
expression is the same as self.
Responsible for returning the list of columns references by\nthis expression. get_group_by_cols() should be called on any\nnested expressions. F() objects, in particular, hold a reference\nto a column.
Returns the expression ready to be sorted in ascending order.
\nnulls_first and nulls_last define how null values are sorted.\nSee Using F() to sort null values for example usage.
Returns the expression ready to be sorted in descending order.
\nnulls_first and nulls_last define how null values are sorted.\nSee Using F() to sort null values for example usage.
Returns self with any modifications required to reverse the sort\norder within an order_by call. As an example, an expression\nimplementing NULLS LAST would change its value to be\nNULLS FIRST. Modifications are only required for expressions that\nimplement sort order like OrderBy. This method is called when\nreverse() is called on a\nqueryset.
You can write your own query expression classes that use, and can integrate\nwith, other query expressions. Let’s step through an example by writing an\nimplementation of the COALESCE SQL function, without using the built-in\nFunc() expressions.
The COALESCE SQL function is defined as taking a list of columns or\nvalues. It will return the first column or value that isn’t NULL.
We’ll start by defining the template to be used for SQL generation and\nan __init__() method to set some attributes:
import copy\nfrom django.db.models import Expression\n\n\nclass Coalesce(Expression):\n template = "COALESCE( %(expressions)s )"\n\n def __init__(self, expressions, output_field):\n super().__init__(output_field=output_field)\n if len(expressions) < 2:\n raise ValueError("expressions must have at least 2 elements")\n for expression in expressions:\n if not hasattr(expression, "resolve_expression"):\n raise TypeError("%r is not an Expression" % expression)\n self.expressions = expressions\nWe do some basic validation on the parameters, including requiring at least 2\ncolumns or values, and ensuring they are expressions. We are requiring\noutput_field here so that Django knows what kind of model\nfield to assign the eventual result to.
\nNow we implement the preprocessing and validation. Since we do not have\nany of our own validation at this point, we delegate to the nested\nexpressions:
\ndef resolve_expression(\n self, query=None, allow_joins=True, reuse=None, summarize=False, for_save=False\n):\n c = self.copy()\n c.is_summary = summarize\n for pos, expression in enumerate(self.expressions):\n c.expressions[pos] = expression.resolve_expression(\n query, allow_joins, reuse, summarize, for_save\n )\n return c\nNext, we write the method responsible for generating the SQL:
\ndef as_sql(self, compiler, connection, template=None):\n sql_expressions, sql_params = [], []\n for expression in self.expressions:\n sql, params = compiler.compile(expression)\n sql_expressions.append(sql)\n sql_params.extend(params)\n template = template or self.template\n data = {"expressions": ",".join(sql_expressions)}\n return template % data, sql_params\n\n\ndef as_oracle(self, compiler, connection):\n """\n Example of vendor specific handling (Oracle in this case).\n Let's make the function name lowercase.\n """\n return self.as_sql(compiler, connection, template="coalesce( %(expressions)s )")\nas_sql() methods can support custom keyword arguments, allowing\nas_vendorname() methods to override data used to generate the SQL string.\nUsing as_sql() keyword arguments for customization is preferable to\nmutating self within as_vendorname() methods as the latter can lead to\nerrors when running on different database backends. If your class relies on\nclass attributes to define data, consider allowing overrides in your\nas_sql() method.
We generate the SQL for each of the expressions by using the\ncompiler.compile() method, and join the result together with commas.\nThen the template is filled out with our data and the SQL and parameters\nare returned.
We’ve also defined a custom implementation that is specific to the Oracle\nbackend. The as_oracle() function will be called instead of as_sql()\nif the Oracle backend is in use.
Finally, we implement the rest of the methods that allow our query expression\nto play nice with other query expressions:
\ndef get_source_expressions(self):\n return self.expressions\n\n\ndef set_source_expressions(self, expressions):\n self.expressions = expressions\nLet’s see how it works:
\n>>> from django.db.models import F, Value, CharField\n>>> qs = Company.objects.annotate(\n... tagline=Coalesce(\n... [F("motto"), F("ticker_name"), F("description"), Value("No Tagline")],\n... output_field=CharField(),\n... )\n... )\n>>> for c in qs:\n... print("%s: %s" % (c.name, c.tagline))\n...\nGoogle: Do No Evil\nApple: AAPL\nYahoo: Internet Company\nDjango Software Foundation: No Tagline\nSince a Func’s keyword arguments for __init__() (**extra) and\nas_sql() (**extra_context) are interpolated into the SQL string rather\nthan passed as query parameters (where the database driver would escape them),\nthey must not contain untrusted user input.
For example, if substring is user-provided, this function is vulnerable to\nSQL injection:
from django.db.models import Func\n\n\nclass Position(Func):\n function = "POSITION"\n template = "%(function)s('%(substring)s' in %(expressions)s)"\n\n def __init__(self, expression, substring):\n # substring=substring is an SQL injection vulnerability!\n super().__init__(expression, substring=substring)\nThis function generates an SQL string without any parameters. Since\nsubstring is passed to super().__init__() as a keyword argument, it’s\ninterpolated into the SQL string before the query is sent to the database.
Here’s a corrected rewrite:
\nclass Position(Func):\n function = "POSITION"\n arg_joiner = " IN "\n\n def __init__(self, expression, substring):\n super().__init__(substring, expression)\nWith substring instead passed as a positional argument, it’ll be passed as\na parameter in the database query.
If you’re using a database backend that uses a different SQL syntax for a\ncertain function, you can add support for it by monkey patching a new method\nonto the function’s class.
\nLet’s say we’re writing a backend for Microsoft’s SQL Server which uses the SQL\nLEN instead of LENGTH for the Length function.\nWe’ll monkey patch a new method called as_sqlserver() onto the Length\nclass:
from django.db.models.functions import Length\n\n\ndef sqlserver_length(self, compiler, connection):\n return self.as_sql(compiler, connection, function="LEN")\n\n\nLength.as_sqlserver = sqlserver_length\nYou can also customize the SQL using the template parameter of as_sql().
We use as_sqlserver() because django.db.connection.vendor returns\nsqlserver for the backend.
Third-party backends can register their functions in the top level\n__init__.py file of the backend package or in a top level expressions.py\nfile (or package) that is imported from the top level __init__.py.
For user projects wishing to patch the backend that they’re using, this code\nshould live in an AppConfig.ready() method.