QuerySet API referenceLink to this heading#This document describes the details of the QuerySet API. It builds on the\nmaterial presented in the model and database\nquery guides, so you'll probably want to read and\nunderstand those documents before reading this one.
Throughout this reference we'll use the example Weblog models presented in the database query guide.
\nQuerySets are evaluatedLink to this heading#Internally, a QuerySet can be constructed, filtered, sliced, and generally\npassed around without actually hitting the database. No database activity\nactually occurs until you do something to evaluate the queryset.
You can evaluate a QuerySet in the following ways:
Iteration. A QuerySet is iterable, and it executes its database\nquery the first time you iterate over it. For example, this will print\nthe headline of all entries in the database:
for e in Entry.objects.all():\n print(e.headline)\nNote: Don't use this if all you want to do is determine if at least one\nresult exists. It's more efficient to use exists().
Slicing. As explained in Membatasi QuerySet, a QuerySet can\nbe sliced, using Python's array-slicing syntax. Slicing an unevaluated\nQuerySet usually returns another unevaluated QuerySet, but Django\nwill execute the database query if you use the "step" parameter of slice\nsyntax, and will return a list. Slicing a QuerySet that has been\nevaluated also returns a list.
Also note that even though slicing an unevaluated QuerySet returns\nanother unevaluated QuerySet, modifying it further (e.g., adding\nmore filters, or modifying ordering) is not allowed, since that does not\ntranslate well into SQL and it would not have a clear meaning either.
Pickling/Caching. See the following section for details of what\nis involved when pickling QuerySets. The important thing for the\npurposes of this section is that the results are read from the database.
repr(). A QuerySet is evaluated when you call repr() on it.\nThis is for convenience in the Python interactive interpreter, so you can\nimmediately see your results when using the API interactively.
len(). A QuerySet is evaluated when you call len() on it.\nThis, as you might expect, returns the length of the result list.
Note: If you only need to determine the number of records in the set (and\ndon't need the actual objects), it's much more efficient to handle a count\nat the database level using SQL's SELECT COUNT(*). Django provides a\ncount() method for precisely this reason.
list(). Force evaluation of a QuerySet by calling list() on\nit. For example:
entry_list = list(Entry.objects.all())\nbool(). Testing a QuerySet in a boolean context, such as using\nbool(), or, and or an if statement, will cause the query\nto be executed. If there is at least one result, the QuerySet is\nTrue, otherwise False. For example:
if Entry.objects.filter(headline="Test"):\n print("There is at least one Entry with the headline Test")\nNote: If you only want to determine if at least one result exists (and don't\nneed the actual objects), it's more efficient to use exists().
QuerySetsLink to this heading#If you pickle a QuerySet, this will force all the results to be loaded\ninto memory prior to pickling. Pickling is usually used as a precursor to\ncaching and when the cached queryset is reloaded, you want the results to\nalready be present and ready for use (reading from the database can take some\ntime, defeating the purpose of caching). This means that when you unpickle a\nQuerySet, it contains the results at the moment it was pickled, rather\nthan the results that are currently in the database.
If you only want to pickle the necessary information to recreate the\nQuerySet from the database at a later time, pickle the query attribute\nof the QuerySet. You can then recreate the original QuerySet (without\nany results loaded) using some code like this:
>>> import pickle\n>>> query = pickle.loads(s) # Assuming 's' is the pickled string.\n>>> qs = MyModel.objects.all()\n>>> qs.query = query # Restore the original 'query'.\nThe query attribute is an opaque object. It represents the internals of\nthe query construction and is not part of the public API. However, it is safe\n(and fully supported) to pickle and unpickle the attribute's contents as\ndescribed here.
QuerySetLink to this heading#Here's the formal declaration of a QuerySet:
Usually when you'll interact with a QuerySet you'll use it by\nchaining filters. To make this work, most\nQuerySet methods return new querysets. These methods are covered in\ndetail later in this section.
The QuerySet class has two public attributes you can use for\nintrospection:
True if the QuerySet is ordered — i.e. has an\norder_by() clause or a default ordering on the model.\nFalse otherwise.
The database that will be used if this query is executed now.
\nQuerySetsLink to this heading#Django provides a range of QuerySet refinement methods that modify either\nthe types of results returned by the QuerySet or the way its SQL query is\nexecuted.
filter()Link to this heading#Returns a new QuerySet containing objects that match the given lookup\nparameters.
The lookup parameters (**kwargs) should be in the format described in\nField lookups below. Multiple parameters are joined via AND in the\nunderlying SQL statement.
If you need to execute more complex queries (for example, queries with OR statements),\nyou can use Q objects.
exclude()Link to this heading#Returns a new QuerySet containing objects that do not match the given\nlookup parameters.
The lookup parameters (**kwargs) should be in the format described in\nField lookups below. Multiple parameters are joined via AND in the\nunderlying SQL statement, and the whole thing is enclosed in a NOT().
This example excludes all entries whose pub_date is later than 2005-1-3\nAND whose headline is "Hello":
Entry.objects.exclude(pub_date__gt=datetime.date(2005, 1, 3), headline='Hello')\nIn SQL terms, that evaluates to:
\nSELECT ...\nWHERE NOT (pub_date > '2005-1-3' AND headline = 'Hello')\nThis example excludes all entries whose pub_date is later than 2005-1-3\nOR whose headline is "Hello":
Entry.objects.exclude(pub_date__gt=datetime.date(2005, 1, 3)).exclude(headline='Hello')\nIn SQL terms, that evaluates to:
\nSELECT ...\nWHERE NOT pub_date > '2005-1-3'\nAND NOT headline = 'Hello'\nNote the second example is more restrictive.
\nIf you need to execute more complex queries (for example, queries with OR statements),\nyou can use Q objects.
annotate()Link to this heading#Annotates each object in the QuerySet with the provided list of query\nexpressions. An expression may be a simple value, a\nreference to a field on the model (or any related models), or an aggregate\nexpression (averages, sums, etc.) that has been computed over the objects that\nare related to the objects in the QuerySet.
Each argument to annotate() is an annotation that will be added\nto each object in the QuerySet that is returned.
The aggregation functions that are provided by Django are described\nin Aggregation Functions below.
\nAnnotations specified using keyword arguments will use the keyword as\nthe alias for the annotation. Anonymous arguments will have an alias\ngenerated for them based upon the name of the aggregate function and\nthe model field that is being aggregated. Only aggregate expressions\nthat reference a single field can be anonymous arguments. Everything\nelse must be a keyword argument.
\nFor example, if you were manipulating a list of blogs, you may want\nto determine how many entries have been made in each blog:
\n>>> from django.db.models import Count\n>>> q = Blog.objects.annotate(Count('entry'))\n# The name of the first blog\n>>> q[0].name\n'Blogasaurus'\n# The number of entries on the first blog\n>>> q[0].entry__count\n42\nThe Blog model doesn't define an entry__count attribute by itself,\nbut by using a keyword argument to specify the aggregate function, you can\ncontrol the name of the annotation:
>>> q = Blog.objects.annotate(number_of_entries=Count('entry'))\n# The number of entries on the first blog, using the name provided\n>>> q[0].number_of_entries\n42\nFor an in-depth discussion of aggregation, see the topic guide on\nAggregation.
\norder_by()Link to this heading#By default, results returned by a QuerySet are ordered by the ordering\ntuple given by the ordering option in the model's Meta. You can\noverride this on a per-QuerySet basis by using the order_by method.
Contoh:
\nEntry.objects.filter(pub_date__year=2005).order_by('-pub_date', 'headline')\nThe result above will be ordered by pub_date descending, then by\nheadline ascending. The negative sign in front of "-pub_date" indicates\ndescending order. Ascending order is implied. To order randomly, use "?",\nlike so:
Entry.objects.order_by('?')\nNote: order_by('?') queries may be expensive and slow, depending on the\ndatabase backend you're using.
To order by a field in a different model, use the same syntax as when you are\nquerying across model relations. That is, the name of the field, followed by a\ndouble underscore (__), followed by the name of the field in the new model,\nand so on for as many models as you want to join. For example:
Entry.objects.order_by('blog__name', 'headline')\nIf you try to order by a field that is a relation to another model, Django will\nuse the default ordering on the related model, or order by the related model's\nprimary key if there is no Meta.ordering specified. For example, since the Blog\nmodel has no default ordering specified:
Entry.objects.order_by('blog')\n... mirip ke:
\nEntry.objects.order_by('blog__id')\nIf Blog had ordering = ['name'], then the first queryset would be\nidentical to:
Entry.objects.order_by('blog__name')\nYou can also order by query expressions by\ncalling asc() or desc() on the expression:
Entry.objects.order_by(Coalesce('summary', 'headline').desc())\nBe cautious when ordering by fields in related models if you are also using\ndistinct(). See the note in distinct() for an explanation of how\nrelated model ordering can change the expected results.
There's no way to specify whether ordering should be case sensitive. With\nrespect to case-sensitivity, Django will order results however your database\nbackend normally orders them.
\nYou can order by a field converted to lowercase with\nLower which will achieve case-consistent\nordering:
Entry.objects.order_by(Lower('headline').desc())\nIf you don't want any ordering to be applied to a query, not even the default\nordering, call order_by() with no parameters.
You can tell if a query is ordered or not by checking the\nQuerySet.ordered attribute, which will be True if the\nQuerySet has been ordered in any way.
Each order_by() call will clear any previous ordering. For example, this\nquery will be ordered by pub_date and not headline:
Entry.objects.order_by('headline').order_by('pub_date')\nreverse()Link to this heading#Use the reverse() method to reverse the order in which a queryset's\nelements are returned. Calling reverse() a second time restores the\nordering back to the normal direction.
To retrieve the "last" five items in a queryset, you could do this:
\nmy_queryset.reverse()[:5]\nNote that this is not quite the same as slicing from the end of a sequence in\nPython. The above example will return the last item first, then the\npenultimate item and so on. If we had a Python sequence and looked at\nseq[-5:], we would see the fifth-last item first. Django doesn't support\nthat mode of access (slicing from the end), because it's not possible to do it\nefficiently in SQL.
Also, note that reverse() should generally only be called on a QuerySet\nwhich has a defined ordering (e.g., when querying against a model which defines\na default ordering, or when using order_by()). If no such ordering is\ndefined for a given QuerySet, calling reverse() on it has no real\neffect (the ordering was undefined prior to calling reverse(), and will\nremain undefined afterward).
distinct()Link to this heading#Returns a new QuerySet that uses SELECT DISTINCT in its SQL query. This\neliminates duplicate rows from the query results.
By default, a QuerySet will not eliminate duplicate rows. In practice, this\nis rarely a problem, because simple queries such as Blog.objects.all()\ndon't introduce the possibility of duplicate result rows. However, if your\nquery spans multiple tables, it's possible to get duplicate results when a\nQuerySet is evaluated. That's when you'd use distinct().
On PostgreSQL only, you can pass positional arguments (*fields) in order to\nspecify the names of fields to which the DISTINCT should apply. This\ntranslates to a SELECT DISTINCT ON SQL query. Here's the difference. For a\nnormal distinct() call, the database compares each field in each row when\ndetermining which rows are distinct. For a distinct() call with specified\nfield names, the database will only compare the specified field names.
Examples (those after the first will only work on PostgreSQL):
\n>>> Author.objects.distinct()\n[...]\n\n>>> Entry.objects.order_by('pub_date').distinct('pub_date')\n[...]\n\n>>> Entry.objects.order_by('blog').distinct('blog')\n[...]\n\n>>> Entry.objects.order_by('author', 'pub_date').distinct('author', 'pub_date')\n[...]\n\n>>> Entry.objects.order_by('blog__name', 'mod_date').distinct('blog__name', 'mod_date')\n[...]\n\n>>> Entry.objects.order_by('author', 'pub_date').distinct('author')\n[...]\nvalues()Link to this heading#Returns a QuerySet that returns dictionaries, rather than model instances,\nwhen used as an iterable.
Each of those dictionaries represents an object, with the keys corresponding to\nthe attribute names of model objects.
\nThis example compares the dictionaries of values() with the normal model\nobjects:
# This list contains a Blog object.\n>>> Blog.objects.filter(name__startswith='Beatles')\n<QuerySet [<Blog: Beatles Blog>]>\n\n# This list contains a dictionary.\n>>> Blog.objects.filter(name__startswith='Beatles').values()\n<QuerySet [{'id': 1, 'name': 'Beatles Blog', 'tagline': 'All the latest Beatles news.'}]>\nThe values() method takes optional positional arguments, *fields, which\nspecify field names to which the SELECT should be limited. If you specify\nthe fields, each dictionary will contain only the field keys/values for the\nfields you specify. If you don't specify the fields, each dictionary will\ncontain a key and value for every field in the database table.
Contoh:
\n>>> Blog.objects.values()\n<QuerySet [{'id': 1, 'name': 'Beatles Blog', 'tagline': 'All the latest Beatles news.'}]>\n>>> Blog.objects.values('id', 'name')\n<QuerySet [{'id': 1, 'name': 'Beatles Blog'}]>\nA few subtleties that are worth mentioning:
\nIf you have a field called foo that is a\nForeignKey, the default values() call\nwill return a dictionary key called foo_id, since this is the name\nof the hidden model attribute that stores the actual value (the foo\nattribute refers to the related model). When you are calling\nvalues() and passing in field names, you can pass in either foo\nor foo_id and you will get back the same thing (the dictionary key\nwill match the field name you passed in).
Sebagai contoh:
\n>>> Entry.objects.values()\n<QuerySet [{'blog_id': 1, 'headline': 'First Entry', ...}, ...]>\n\n>>> Entry.objects.values('blog')\n<QuerySet [{'blog': 1}, ...]>\n\n>>> Entry.objects.values('blog_id')\n<QuerySet [{'blog_id': 1}, ...]>\nWhen using values() together with distinct(), be aware that\nordering can affect the results. See the note in distinct() for\ndetails.
If you use a values() clause after an extra() call,\nany fields defined by a select argument in the extra() must\nbe explicitly included in the values() call. Any extra() call\nmade after a values() call will have its extra selected fields\nignored.
Calling only() and defer() after values() doesn't make\nsense, so doing so will raise a NotImplementedError.
It is useful when you know you're only going to need values from a small number\nof the available fields and you won't need the functionality of a model\ninstance object. It's more efficient to select only the fields you need to use.
\nFinally, note that you can call filter(), order_by(), etc. after the\nvalues() call, that means that these two calls are identical:
Blog.objects.values().order_by('id')\nBlog.objects.order_by('id').values()\nThe people who made Django prefer to put all the SQL-affecting methods first,\nfollowed (optionally) by any output-affecting methods (such as values()),\nbut it doesn't really matter. This is your chance to really flaunt your\nindividualism.
You can also refer to fields on related models with reverse relations through\nOneToOneField, ForeignKey and ManyToManyField attributes:
>>> Blog.objects.values('name', 'entry__headline')\n<QuerySet [{'name': 'My blog', 'entry__headline': 'An entry'},\n {'name': 'My blog', 'entry__headline': 'Another entry'}, ...]>\nvalues_list()Link to this heading#This is similar to values() except that instead of returning dictionaries,\nit returns tuples when iterated over. Each tuple contains the value from the\nrespective field passed into the values_list() call — so the first item is\nthe first field, etc. For example:
>>> Entry.objects.values_list('id', 'headline')\n[(1, 'First entry'), ...]\nIf you only pass in a single field, you can also pass in the flat\nparameter. If True, this will mean the returned results are single values,\nrather than one-tuples. An example should make the difference clearer:
>>> Entry.objects.values_list('id').order_by('id')\n[(1,), (2,), (3,), ...]\n\n>>> Entry.objects.values_list('id', flat=True).order_by('id')\n[1, 2, 3, ...]\nIt is an error to pass in flat when there is more than one field.
If you don't pass any values to values_list(), it will return all the\nfields in the model, in the order they were declared.
A common need is to get a specific field value of a certain model instance. To\nachieve that, use values_list() followed by a get() call:
>>> Entry.objects.values_list('headline', flat=True).get(pk=1)\n'First entry'\nvalues() and values_list() are both intended as optimizations for a\nspecific use case: retrieving a subset of data without the overhead of creating\na model instance. This metaphor falls apart when dealing with many-to-many and\nother multivalued relations (such as the one-to-many relation of a reverse\nforeign key) because the "one row, one object" assumption doesn't hold.
For example, notice the behavior when querying across a\nManyToManyField:
>>> Author.objects.values_list('name', 'entry__headline')\n[('Noam Chomsky', 'Impressions of Gaza'),\n ('George Orwell', 'Why Socialists Do Not Believe in Fun'),\n ('George Orwell', 'In Defence of English Cooking'),\n ('Don Quixote', None)]\nAuthors with multiple entries appear multiple times and authors without any\nentries have None for the entry headline.
Similarly, when querying a reverse foreign key, None appears for entries\nnot having any author:
>>> Entry.objects.values_list('authors')\n[('Noam Chomsky',), ('George Orwell',), (None,)]\ndates()Link to this heading#Returns a QuerySet that evaluates to a list of datetime.date\nobjects representing all available dates of a particular kind within the\ncontents of the QuerySet.
field should be the name of a DateField of your model.\nkind should be either "year", "month" or "day". Each\ndatetime.date object in the result list is "truncated" to the given\ntype.
"year" returns a list of all distinct year values for the field.
"month" returns a list of all distinct year/month values for the\nfield.
"day" returns a list of all distinct year/month/day values for the\nfield.
order, which defaults to 'ASC', should be either 'ASC' or\n'DESC'. This specifies how to order the results.
Examples:
\n>>> Entry.objects.dates('pub_date', 'year')\n[datetime.date(2005, 1, 1)]\n>>> Entry.objects.dates('pub_date', 'month')\n[datetime.date(2005, 2, 1), datetime.date(2005, 3, 1)]\n>>> Entry.objects.dates('pub_date', 'day')\n[datetime.date(2005, 2, 20), datetime.date(2005, 3, 20)]\n>>> Entry.objects.dates('pub_date', 'day', order='DESC')\n[datetime.date(2005, 3, 20), datetime.date(2005, 2, 20)]\n>>> Entry.objects.filter(headline__contains='Lennon').dates('pub_date', 'day')\n[datetime.date(2005, 3, 20)]\ndatetimes()Link to this heading#Returns a QuerySet that evaluates to a list of datetime.datetime\nobjects representing all available dates of a particular kind within the\ncontents of the QuerySet.
field_name should be the name of a DateTimeField of your model.
kind should be either "year", "month", "day", "hour",\n"minute" or "second". Each datetime.datetime object in the result\nlist is "truncated" to the given type.
order, which defaults to 'ASC', should be either 'ASC' or\n'DESC'. This specifies how to order the results.
tzinfo defines the time zone to which datetimes are converted prior to\ntruncation. Indeed, a given datetime has different representations depending\non the time zone in use. This parameter must be a datetime.tzinfo\nobject. If it's None, Django uses the current time zone. It has no effect when USE_TZ is\nFalse.
none()Link to this heading#Calling none() will create a queryset that never returns any objects and no\nquery will be executed when accessing the results. A qs.none() queryset\nis an instance of EmptyQuerySet.
Examples:
\n>>> Entry.objects.none()\n<QuerySet []>\n>>> from django.db.models.query import EmptyQuerySet\n>>> isinstance(Entry.objects.none(), EmptyQuerySet)\nTrue\nall()Link to this heading#Returns a copy of the current QuerySet (or QuerySet subclass). This\ncan be useful in situations where you might want to pass in either a model\nmanager or a QuerySet and do further filtering on the result. After calling\nall() on either object, you'll definitely have a QuerySet to work with.
When a QuerySet is evaluated, it\ntypically caches its results. If the data in the database might have changed\nsince a QuerySet was evaluated, you can get updated results for the same\nquery by calling all() on a previously evaluated QuerySet.
extra()Link to this heading#Sometimes, the Django query syntax by itself can't easily express a complex\nWHERE clause. For these edge cases, Django provides the extra()\nQuerySet modifier — a hook for injecting specific clauses into the SQL\ngenerated by a QuerySet.
By definition, these extra lookups may not be portable to different database\nengines (because you're explicitly writing SQL code) and violate the DRY\nprinciple, so you should avoid them if possible.
\nSpecify one or more of params, select, where or tables. None\nof the arguments is required, but you should use at least one of them.
select
The select argument lets you put extra fields in the SELECT\nclause. It should be a dictionary mapping attribute names to SQL\nclauses to use to calculate that attribute.
Contoh:
\nEntry.objects.extra(select={'is_recent': "pub_date > '2006-01-01'"})\nAs a result, each Entry object will have an extra attribute,\nis_recent, a boolean representing whether the entry's pub_date\nis greater than Jan. 1, 2006.
Django inserts the given SQL snippet directly into the SELECT\nstatement, so the resulting SQL of the above example would be something\nlike:
SELECT blog_entry.*, (pub_date > '2006-01-01') AS is_recent\nFROM blog_entry;\nThe next example is more advanced; it does a subquery to give each\nresulting Blog object an entry_count attribute, an integer count\nof associated Entry objects:
Blog.objects.extra(\n select={\n 'entry_count': 'SELECT COUNT(*) FROM blog_entry WHERE blog_entry.blog_id = blog_blog.id'\n },\n)\nIn this particular case, we're exploiting the fact that the query will\nalready contain the blog_blog table in its FROM clause.
The resulting SQL of the above example would be:
\nSELECT blog_blog.*, (SELECT COUNT(*) FROM blog_entry WHERE blog_entry.blog_id = blog_blog.id) AS entry_count\nFROM blog_blog;\nNote that the parentheses required by most database engines around\nsubqueries are not required in Django's select clauses. Also note\nthat some database backends, such as some MySQL versions, don't support\nsubqueries.
In some rare cases, you might wish to pass parameters to the SQL\nfragments in extra(select=...). For this purpose, use the\nselect_params parameter. Since select_params is a sequence and\nthe select attribute is a dictionary, some care is required so that\nthe parameters are matched up correctly with the extra select pieces.\nIn this situation, you should use a collections.OrderedDict for\nthe select value, not just a normal Python dictionary.
Ini akan bekerja, sebagai contoh:
\nBlog.objects.extra(\n select=OrderedDict([('a', '%s'), ('b', '%s')]),\n select_params=('one', 'two'))\nIf you need to use a literal %s inside your select string, use\nthe sequence %%s.
where / tables
You can define explicit SQL WHERE clauses — perhaps to perform\nnon-explicit joins — by using where. You can manually add tables to\nthe SQL FROM clause by using tables.
where and tables both take a list of strings. All where\nparameters are "AND"ed to any other search criteria.
Contoh:
\nEntry.objects.extra(where=["foo='a' OR bar = 'a'", "baz = 'a'"])\n...translates (roughly) into the following SQL:
\nSELECT * FROM blog_entry WHERE (foo='a' OR bar='a') AND (baz='a')\nBe careful when using the tables parameter if you're specifying\ntables that are already used in the query. When you add extra tables\nvia the tables parameter, Django assumes you want that table\nincluded an extra time, if it is already included. That creates a\nproblem, since the table name will then be given an alias. If a table\nappears multiple times in an SQL statement, the second and subsequent\noccurrences must use aliases so the database can tell them apart. If\nyou're referring to the extra table you added in the extra where\nparameter this is going to cause errors.
Normally you'll only be adding extra tables that don't already appear\nin the query. However, if the case outlined above does occur, there are\na few solutions. First, see if you can get by without including the\nextra table and use the one already in the query. If that isn't\npossible, put your extra() call at the front of the queryset\nconstruction so that your table is the first use of that table.\nFinally, if all else fails, look at the query produced and rewrite your\nwhere addition to use the alias given to your extra table. The\nalias will be the same each time you construct the queryset in the same\nway, so you can rely upon the alias name to not change.
order_by
If you need to order the resulting queryset using some of the new\nfields or tables you have included via extra() use the order_by\nparameter to extra() and pass in a sequence of strings. These\nstrings should either be model fields (as in the normal\norder_by() method on querysets), of the form\ntable_name.column_name or an alias for a column that you specified\nin the select parameter to extra().
Sebagai contoh:
\nq = Entry.objects.extra(select={'is_recent': "pub_date > '2006-01-01'"})\nq = q.extra(order_by = ['-is_recent'])\nThis would sort all the items for which is_recent is true to the\nfront of the result set (True sorts before False in a\ndescending ordering).
This shows, by the way, that you can make multiple calls to extra()\nand it will behave as you expect (adding new constraints each time).
params
The where parameter described above may use standard Python\ndatabase string placeholders — '%s' to indicate parameters the\ndatabase engine should automatically quote. The params argument is\na list of any extra parameters to be substituted.
Contoh:
\nEntry.objects.extra(where=['headline=%s'], params=['Lennon'])\nAlways use params instead of embedding values directly into\nwhere because params will ensure values are quoted correctly\naccording to your particular backend. For example, quotes will be\nescaped correctly.
Buruk:
\nEntry.objects.extra(where=["headline='Lennon'"])\nBaik:
\nEntry.objects.extra(where=['headline=%s'], params=['Lennon'])\ndefer()Link to this heading#In some complex data-modeling situations, your models might contain a lot of\nfields, some of which could contain a lot of data (for example, text fields),\nor require expensive processing to convert them to Python objects. If you are\nusing the results of a queryset in some situation where you don't know\nif you need those particular fields when you initially fetch the data, you can\ntell Django not to retrieve them from the database.
\nThis is done by passing the names of the fields to not load to defer():
Entry.objects.defer("headline", "body")\nA queryset that has deferred fields will still return model instances. Each\ndeferred field will be retrieved from the database if you access that field\n(one at a time, not all the deferred fields at once).
\nYou can make multiple calls to defer(). Each call adds new fields to the\ndeferred set:
# Defers both the body and headline fields.\nEntry.objects.defer("body").filter(rating=5).defer("headline")\nThe order in which fields are added to the deferred set does not matter.\nCalling defer() with a field name that has already been deferred is\nharmless (the field will still be deferred).
You can defer loading of fields in related models (if the related models are\nloading via select_related()) by using the standard double-underscore\nnotation to separate related fields:
Blog.objects.select_related().defer("entry__headline", "entry__body")\nIf you want to clear the set of deferred fields, pass None as a parameter\nto defer():
# Load all fields immediately.\nmy_queryset.defer(None)\nSome fields in a model won't be deferred, even if you ask for them. You can\nnever defer the loading of the primary key. If you are using\nselect_related() to retrieve related models, you shouldn't defer the\nloading of the field that connects from the primary model to the related\none, doing so will result in an error.
only()Link to this heading#The only() method is more or less the opposite of defer(). You call\nit with the fields that should not be deferred when retrieving a model. If\nyou have a model where almost all the fields need to be deferred, using\nonly() to specify the complementary set of fields can result in simpler\ncode.
Suppose you have a model with fields name, age and biography. The\nfollowing two querysets are the same, in terms of deferred fields:
Person.objects.defer("age", "biography")\nPerson.objects.only("name")\nWhenever you call only() it replaces the set of fields to load\nimmediately. The method's name is mnemonic: only those fields are loaded\nimmediately; the remainder are deferred. Thus, successive calls to only()\nresult in only the final fields being considered:
# This will defer all fields except the headline.\nEntry.objects.only("body", "rating").only("headline")\nSince defer() acts incrementally (adding fields to the deferred list), you\ncan combine calls to only() and defer() and things will behave\nlogically:
# Final result is that everything except "headline" is deferred.\nEntry.objects.only("headline", "body").defer("body")\n\n# Final result loads headline and body immediately (only() replaces any\n# existing set of fields).\nEntry.objects.defer("body").only("headline", "body")\nAll of the cautions in the note for the defer() documentation apply to\nonly() as well. Use it cautiously and only after exhausting your other\noptions.
Using only() and omitting a field requested using select_related()\nis an error as well.
using()Link to this heading#This method is for controlling which database the QuerySet will be\nevaluated against if you are using more than one database. The only argument\nthis method takes is the alias of a database, as defined in\nDATABASES.
Sebagai contoh:
\n# queries the database with the 'default' alias.\n>>> Entry.objects.all()\n\n# queries the database with the 'backup' alias\n>>> Entry.objects.using('backup')\nselect_for_update()Link to this heading#Returns a queryset that will lock rows until the end of the transaction,\ngenerating a SELECT ... FOR UPDATE SQL statement on supported databases.
Sebagai contoh:
\nentries = Entry.objects.select_for_update().filter(author=request.user)\nAll matched entries will be locked until the end of the transaction block,\nmeaning that other transactions will be prevented from changing or acquiring\nlocks on them.
\nUsually, if another transaction has already acquired a lock on one of the\nselected rows, the query will block until the lock is released. If this is\nnot the behavior you want, call select_for_update(nowait=True). This will\nmake the call non-blocking. If a conflicting lock is already acquired by\nanother transaction, DatabaseError will be raised when the\nqueryset is evaluated.
Currently, the postgresql, oracle, and mysql database\nbackends support select_for_update(). However, MySQL has no support for the\nnowait argument. Obviously, users of external third-party backends should\ncheck with their backend's documentation for specifics in those cases.
Passing nowait=True to select_for_update() using database backends that\ndo not support nowait, such as MySQL, will cause a\nDatabaseError to be raised. This is in order to prevent code\nunexpectedly blocking.
Evaluating a queryset with select_for_update() in autocommit mode on\nbackends which support SELECT ... FOR UPDATE is a\nTransactionManagementError error because the\nrows are not locked in that case. If allowed, this would facilitate data\ncorruption and could easily be caused by calling code that expects to be run in\na transaction outside of one.
Using select_for_update() on backends which do not support\nSELECT ... FOR UPDATE (such as SQLite) will have no effect.\nSELECT ... FOR UPDATE will not be added to the query, and an error isn't\nraised if select_for_update() is used in autocommit mode.
raw()Link to this heading#Takes a raw SQL query, executes it, and returns a\ndjango.db.models.query.RawQuerySet instance. This RawQuerySet instance\ncan be iterated over just like an normal QuerySet to provide object instances.
Lihat Performing raw SQL queries untuk informasi lebih.
\n\nQuerySetsLink to this heading#The following QuerySet methods evaluate the QuerySet and return\nsomething other than a QuerySet.
These methods do not use a cache (see Caching and QuerySets). Rather,\nthey query the database each time they're called.
\nget()Link to this heading#Returns the object matching the given lookup parameters, which should be in\nthe format described in Field lookups.
\nget() raises MultipleObjectsReturned if more\nthan one object was found. The\nMultipleObjectsReturned exception is an\nattribute of the model class.
get() raises a DoesNotExist exception if an\nobject wasn't found for the given parameters. This exception is an attribute\nof the model class. Example:
Entry.objects.get(id='foo') # raises Entry.DoesNotExist\nThe DoesNotExist exception inherits from\ndjango.core.exceptions.ObjectDoesNotExist, so you can target multiple\nDoesNotExist exceptions. Example:
from django.core.exceptions import ObjectDoesNotExist\ntry:\n e = Entry.objects.get(id=3)\n b = Blog.objects.get(id=1)\nexcept ObjectDoesNotExist:\n print("Either the entry or blog doesn't exist.")\nIf you expect a queryset to return one row, you can use get() without any\narguments to return the object for that row:
entry = Entry.objects.filter(...).exclude(...).get()\ncreate()Link to this heading#A convenience method for creating an object and saving it all in one step. Thus:
\np = Person.objects.create(first_name="Bruce", last_name="Springsteen")\ndan:
\np = Person(first_name="Bruce", last_name="Springsteen")\np.save(force_insert=True)\nadalah setara.
\nThe force_insert parameter is documented\nelsewhere, but all it means is that a new object will always be created.\nNormally you won't need to worry about this. However, if your model contains a\nmanual primary key value that you set and if that value already exists in the\ndatabase, a call to create() will fail with an\nIntegrityError since primary keys must be unique. Be\nprepared to handle the exception if you are using manual primary keys.
get_or_create()Link to this heading#A convenience method for looking up an object with the given kwargs (may be\nempty if your model has defaults for all fields), creating one if necessary.
Returns a tuple of (object, created), where object is the retrieved or\ncreated object and created is a boolean specifying whether a new object was\ncreated.
This is meant as a shortcut to boilerplatish code. For example:
\ntry:\n obj = Person.objects.get(first_name='John', last_name='Lennon')\nexcept Person.DoesNotExist:\n obj = Person(first_name='John', last_name='Lennon', birthday=date(1940, 10, 9))\n obj.save()\nThis pattern gets quite unwieldy as the number of fields in a model goes up.\nThe above example can be rewritten using get_or_create() like so:
obj, created = Person.objects.get_or_create(\n first_name='John',\n last_name='Lennon',\n defaults={'birthday': date(1940, 10, 9)},\n)\nAny keyword arguments passed to get_or_create() — except an optional one\ncalled defaults — will be used in a get() call. If an object is\nfound, get_or_create() returns a tuple of that object and False. If\nmultiple objects are found, get_or_create raises\nMultipleObjectsReturned. If an object is not\nfound, get_or_create() will instantiate and save a new object, returning a\ntuple of the new object and True. The new object will be created roughly\naccording to this algorithm:
params = {k: v for k, v in kwargs.items() if '__' not in k}\nparams.update(defaults)\nobj = self.model(**params)\nobj.save()\nIn English, that means start with any non-'defaults' keyword argument that\ndoesn't contain a double underscore (which would indicate a non-exact lookup).\nThen add the contents of defaults, overriding any keys if necessary, and\nuse the result as the keyword arguments to the model class. As hinted at\nabove, this is a simplification of the algorithm that is used, but it contains\nall the pertinent details. The internal implementation has some more\nerror-checking than this and handles some extra edge-conditions; if you're\ninterested, read the code.
If you have a field named defaults and want to use it as an exact lookup in\nget_or_create(), just use 'defaults__exact', like so:
Foo.objects.get_or_create(defaults__exact='bar', defaults={'defaults': 'baz'})\nThe get_or_create() method has similar error behavior to create()\nwhen you're using manually specified primary keys. If an object needs to be\ncreated and the key already exists in the database, an\nIntegrityError will be raised.
This method is atomic assuming correct usage, correct database configuration,\nand correct behavior of the underlying database. However, if uniqueness is not\nenforced at the database level for the kwargs used in a get_or_create\ncall (see unique or\nunique_together), this method is prone to a\nrace-condition which can result in multiple rows with the same parameters being\ninserted simultaneously.
If you are using MySQL, be sure to use the READ COMMITTED isolation level\nrather than REPEATABLE READ (the default), otherwise you may see cases\nwhere get_or_create will raise an IntegrityError but the\nobject won't appear in a subsequent get()\ncall.
Finally, a word on using get_or_create() in Django views. Please make sure\nto use it only in POST requests unless you have a good reason not to.\nGET requests shouldn't have any effect on data. Instead, use POST\nwhenever a request to a page has a side effect on your data. For more, see\nSafe methods in the HTTP spec.
update_or_create()Link to this heading#A convenience method for updating an object with the given kwargs, creating\na new one if necessary. The defaults is a dictionary of (field, value)\npairs used to update the object.
Returns a tuple of (object, created), where object is the created or\nupdated object and created is a boolean specifying whether a new object was\ncreated.
The update_or_create method tries to fetch an object from database based on\nthe given kwargs. If a match is found, it updates the fields passed in the\ndefaults dictionary.
This is meant as a shortcut to boilerplatish code. For example:
\ndefaults = {'first_name': 'Bob'}\ntry:\n obj = Person.objects.get(first_name='John', last_name='Lennon')\n for key, value in defaults.items():\n setattr(obj, key, value)\n obj.save()\nexcept Person.DoesNotExist:\n new_values = {'first_name': 'John', 'last_name': 'Lennon'}\n new_values.update(defaults)\n obj = Person(**new_values)\n obj.save()\nThis pattern gets quite unwieldy as the number of fields in a model goes up.\nThe above example can be rewritten using update_or_create() like so:
obj, created = Person.objects.update_or_create(\n first_name='John', last_name='Lennon',\n defaults={'first_name': 'Bob'},\n)\nFor detailed description how names passed in kwargs are resolved see\nget_or_create().
As described above in get_or_create(), this method is prone to a\nrace-condition which can result in multiple rows being inserted simultaneously\nif uniqueness is not enforced at the database level.
bulk_create()Link to this heading#This method inserts the provided list of objects into the database in an\nefficient manner (generally only 1 query, no matter how many objects there\nare):
\n>>> Entry.objects.bulk_create([\n... Entry(headline='This is a test'),\n... Entry(headline='This is only a test'),\n... ])\nThis has a number of caveats though:
\nThe model's save() method will not be called, and the pre_save and\npost_save signals will not be sent.
It does not work with child models in a multi-table inheritance scenario.
If the model's primary key is an AutoField it\ndoes not retrieve and set the primary key attribute, as save() does,\nunless the database backend supports it (currently PostgreSQL).
It does not work with many-to-many relationships.
The batch_size parameter controls how many objects are created in single\nquery. The default is to create all objects in one batch, except for SQLite\nwhere the default is such that at most 999 variables per query are used.
count()Link to this heading#Returns an integer representing the number of objects in the database matching\nthe QuerySet. The count() method never raises exceptions.
Contoh:
\n# Returns the total number of entries in the database.\nEntry.objects.count()\n\n# Returns the number of entries whose headline contains 'Lennon'\nEntry.objects.filter(headline__contains='Lennon').count()\nA count() call performs a SELECT COUNT(*) behind the scenes, so you\nshould always use count() rather than loading all of the record into Python\nobjects and calling len() on the result (unless you need to load the\nobjects into memory anyway, in which case len() will be faster).
Depending on which database you're using (e.g. PostgreSQL vs. MySQL),\ncount() may return a long integer instead of a normal Python integer. This\nis an underlying implementation quirk that shouldn't pose any real-world\nproblems.
Note that if you want the number of items in a QuerySet and are also\nretrieving model instances from it (for example, by iterating over it), it's\nprobably more efficient to use len(queryset) which won't cause an extra\ndatabase query like count() would.
in_bulk()Link to this heading#Takes a list of primary-key values and returns a dictionary mapping each\nprimary-key value to an instance of the object with the given ID. If a list\nisn't provided, all objects in the queryset are returned.
\nContoh:
\n>>> Blog.objects.in_bulk([1])\n{1: <Blog: Beatles Blog>}\n>>> Blog.objects.in_bulk([1, 2])\n{1: <Blog: Beatles Blog>, 2: <Blog: Cheddar Talk>}\n>>> Blog.objects.in_bulk([])\n{}\n>>> Blog.objects.in_bulk()\n{1: <Blog: Beatles Blog>, 2: <Blog: Cheddar Talk>, 3: <Blog: Django Weblog>}\nIf you pass in_bulk() an empty list, you'll get an empty dictionary.
iterator()Link to this heading#Evaluates the QuerySet (by performing the query) and returns an iterator\n(see PEP 234) over the results. A QuerySet typically caches its results\ninternally so that repeated evaluations do not result in additional queries. In\ncontrast, iterator() will read results directly, without doing any caching\nat the QuerySet level (internally, the default iterator calls iterator()\nand caches the return value). For a QuerySet which returns a large number of\nobjects that you only need to access once, this can result in better\nperformance and a significant reduction in memory.
Note that using iterator() on a QuerySet which has already been\nevaluated will force it to evaluate again, repeating the query.
Juga, penggunaan iterator() menyebabkan panggilan prefetch_related() sebelumnya dapat diabaikan sejak dua optimalisasi ini tidak masuk akan bersama-sama.
latest()Link to this heading#Returns the latest object in the table, by date, using the field_name\nprovided as the date field.
This example returns the latest Entry in the table, according to the\npub_date field:
Entry.objects.latest('pub_date')\nIf your model's Meta specifies\nget_latest_by, you can leave off the\nfield_name argument to earliest() or latest(). Django will use the\nfield specified in get_latest_by by default.
Like get(), earliest() and latest() raise\nDoesNotExist if there is no object with the\ngiven parameters.
Note that earliest() and latest() exist purely for convenience and\nreadability.
earliest()Link to this heading#Works otherwise like latest() except\nthe direction is changed.
first()Link to this heading#Returns the first object matched by the queryset, or None if there\nis no matching object. If the QuerySet has no ordering defined, then the\nqueryset is automatically ordered by the primary key.
Contoh:
\np = Article.objects.order_by('title', 'pub_date').first()\nNote that first() is a convenience method, the following code sample is\nequivalent to the above example:
try:\n p = Article.objects.order_by('title', 'pub_date')[0]\nexcept IndexError:\n p = None\nlast()Link to this heading#Works like first(), but returns the last object in the queryset.
aggregate()Link to this heading#Returns a dictionary of aggregate values (averages, sums, etc.) calculated over\nthe QuerySet. Each argument to aggregate() specifies a value that will\nbe included in the dictionary that is returned.
The aggregation functions that are provided by Django are described in\nAggregation Functions below. Since aggregates are also query\nexpressions, you may combine aggregates with other\naggregates or values to create complex aggregates.
\nAggregates specified using keyword arguments will use the keyword as the name\nfor the annotation. Anonymous arguments will have a name generated for them\nbased upon the name of the aggregate function and the model field that is being\naggregated. Complex aggregates cannot use anonymous arguments and must specify\na keyword argument as an alias.
\nFor example, when you are working with blog entries, you may want to know the\nnumber of authors that have contributed blog entries:
\n>>> from django.db.models import Count\n>>> q = Blog.objects.aggregate(Count('entry'))\n{'entry__count': 16}\nBy using a keyword argument to specify the aggregate function, you can\ncontrol the name of the aggregation value that is returned:
\n>>> q = Blog.objects.aggregate(number_of_entries=Count('entry'))\n{'number_of_entries': 16}\nFor an in-depth discussion of aggregation, see the topic guide on\nAggregation.
\nexists()Link to this heading#Returns True if the QuerySet contains any results, and False\nif not. This tries to perform the query in the simplest and fastest way\npossible, but it does execute nearly the same query as a normal\nQuerySet query.
exists() is useful for searches relating to both\nobject membership in a QuerySet and to the existence of any objects in\na QuerySet, particularly in the context of a large QuerySet.
The most efficient method of finding whether a model with a unique field\n(e.g. primary_key) is a member of a QuerySet is:
entry = Entry.objects.get(pk=123)\nif some_queryset.filter(pk=entry.pk).exists():\n print("Entry contained in queryset")\nWhich will be faster than the following which requires evaluating and iterating\nthrough the entire queryset:
\nif entry in some_queryset:\n print("Entry contained in QuerySet")\nAnd to find whether a queryset contains any items:
\nif some_queryset.exists():\n print("There is at least one object in some_queryset")\nYang akan menjadi lebih cepat daripada:
\nif some_queryset:\n print("There is at least one object in some_queryset")\n... but not by a large degree (hence needing a large queryset for efficiency\ngains).
\nAdditionally, if a some_queryset has not yet been evaluated, but you know\nthat it will be at some point, then using some_queryset.exists() will do\nmore overall work (one query for the existence check plus an extra one to later\nretrieve the results) than simply using bool(some_queryset), which\nretrieves the results and then checks if any were returned.
update()Link to this heading#Performs an SQL update query for the specified fields, and returns\nthe number of rows matched (which may not be equal to the number of rows\nupdated if some rows already have the new value).
\nFor example, to turn comments off for all blog entries published in 2010,\nyou could do this:
\n>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False)\n(This assumes your Entry model has fields pub_date and comments_on.)
You can update multiple fields — there's no limit on how many. For example,\nhere we update the comments_on and headline fields:
>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False, headline='This is old')\nThe update() method is applied instantly, and the only restriction on the\nQuerySet that is updated is that it can only update columns in the\nmodel's main table, not on related models. You can't do this, for example:
>>> Entry.objects.update(blog__name='foo') # Won't work!\nFiltering based on related fields is still possible, though:
\n>>> Entry.objects.filter(blog__id=1).update(comments_on=True)\nYou cannot call update() on a QuerySet that has had a slice taken\nor can otherwise no longer be filtered.
Cara update() mengembalikan sejumlah dari baris yang terpengaruh:
>>> Entry.objects.filter(id=64).update(comments_on=True)\n1\n\n>>> Entry.objects.filter(slug='nonexistent-slug').update(comments_on=True)\n0\n\n>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False)\n132\nIf you're just updating a record and don't need to do anything with the model\nobject, the most efficient approach is to call update(), rather than\nloading the model object into memory. For example, instead of doing this:
e = Entry.objects.get(id=10)\ne.comments_on = False\ne.save()\n...lakukan ini:
\nEntry.objects.filter(id=10).update(comments_on=False)\nUsing update() also prevents a race condition wherein something might\nchange in your database in the short period of time between loading the object\nand calling save().
Finally, realize that update() does an update at the SQL level and, thus,\ndoes not call any save() methods on your models, nor does it emit the\npre_save or\npost_save signals (which are a consequence of\ncalling Model.save()). If you want to\nupdate a bunch of records for a model that has a custom\nsave() method, loop over them and call\nsave(), like this:
for e in Entry.objects.filter(pub_date__year=2010):\n e.comments_on = False\n e.save()\ndelete()Link to this heading#Performs an SQL delete query on all rows in the QuerySet and\nreturns the number of objects deleted and a dictionary with the number of\ndeletions per object type.
The delete() is applied instantly. You cannot call delete() on a\nQuerySet that has had a slice taken or can otherwise no longer be\nfiltered.
For example, to delete all the entries in a particular blog:
\n>>> b = Blog.objects.get(pk=1)\n\n# Delete all the entries belonging to this Blog.\n>>> Entry.objects.filter(blog=b).delete()\n(4, {'weblog.Entry': 2, 'weblog.Entry_authors': 2})\nBy default, Django's ForeignKey emulates the SQL\nconstraint ON DELETE CASCADE — in other words, any objects with foreign\nkeys pointing at the objects to be deleted will be deleted along with them.\nFor example:
>>> blogs = Blog.objects.all()\n\n# This will delete all Blogs and all of their Entry objects.\n>>> blogs.delete()\n(5, {'weblog.Blog': 1, 'weblog.Entry': 2, 'weblog.Entry_authors': 2})\nKebiasaan turunan ini dapat di sesuaikan melalui argumen on_delete ke ForeignKey.
The delete() method does a bulk delete and does not call any delete()\nmethods on your models. It does, however, emit the\npre_delete and\npost_delete signals for all deleted objects\n(including cascaded deletions).
Django needs to fetch objects into memory to send signals and handle cascades.\nHowever, if there are no cascades and no signals, then Django may take a\nfast-path and delete objects without fetching into memory. For large\ndeletes this can result in significantly reduced memory usage. The amount of\nexecuted queries can be reduced, too.
\nForeignKeys which are set to on_delete\nDO_NOTHING do not prevent taking the fast-path in deletion.
Note that the queries generated in object deletion is an implementation\ndetail subject to change.
\nas_manager()Link to this heading#Class method that returns an instance of Manager\nwith a copy of the QuerySet’s methods. See\nMembuat pengelola dengan cara QuerySet for more details.
Field lookupsLink to this heading#Field lookups are how you specify the meat of an SQL WHERE clause. They're\nspecified as keyword arguments to the QuerySet methods filter(),\nexclude() and get().
For an introduction, see models and database queries documentation.
\nDjango's built-in lookups are listed below. It is also possible to write\ncustom lookups for model fields.
\nAs a convenience when no lookup type is provided (like in\nEntry.objects.get(id=14)) the lookup type is assumed to be exact.
exactLink to this heading#Exact match. If the value provided for comparison is None, it will be\ninterpreted as an SQL NULL (see isnull for more details).
Examples:
\nEntry.objects.get(id__exact=14)\nEntry.objects.get(id__exact=None)\nSQL equivalents:
\nSELECT ... WHERE id = 14;\nSELECT ... WHERE id IS NULL;\niexactLink to this heading#Case-insensitive exact match. If the value provided for comparison is None,\nit will be interpreted as an SQL NULL (see isnull for more\ndetails).
Contoh:
\nBlog.objects.get(name__iexact='beatles blog')\nBlog.objects.get(name__iexact=None)\nSQL equivalents:
\nSELECT ... WHERE name ILIKE 'beatles blog';\nSELECT ... WHERE name IS NULL;\nNote the first query will match 'Beatles Blog', 'beatles blog',\n'BeAtLes BLoG', etc.
containsLink to this heading#Case-sensitive containment test.
\nContoh:
\nEntry.objects.get(headline__contains='Lennon')\nSQL setara:
\nSELECT ... WHERE headline LIKE '%Lennon%';\nNote this will match the headline 'Lennon honored today' but not 'lennon\nhonored today'.
icontainsLink to this heading#Case-insensitive containment test.
\nContoh:
\nEntry.objects.get(headline__icontains='Lennon')\nSQL setara:
\nSELECT ... WHERE headline ILIKE '%Lennon%';\ninLink to this heading#Dalam daftar yang diberikan.
\nContoh:
\nEntry.objects.filter(id__in=[1, 3, 4])\nSQL setara:
\nSELECT ... WHERE id IN (1, 3, 4);\nYou can also use a queryset to dynamically evaluate the list of values\ninstead of providing a list of literal values:
\ninner_qs = Blog.objects.filter(name__contains='Cheddar')\nentries = Entry.objects.filter(blog__in=inner_qs)\nThis queryset will be evaluated as subselect statement:
\nSELECT ... WHERE blog.id IN (SELECT id FROM ... WHERE NAME LIKE '%Cheddar%')\nIf you pass in a QuerySet resulting from values() or values_list()\nas the value to an __in lookup, you need to ensure you are only extracting\none field in the result. For example, this will work (filtering on the blog\nnames):
inner_qs = Blog.objects.filter(name__contains='Ch').values('name')\nentries = Entry.objects.filter(blog__name__in=inner_qs)\nThis example will raise an exception, since the inner query is trying to\nextract two field values, where only one is expected:
\n# Bad code! Will raise a TypeError.\ninner_qs = Blog.objects.filter(name__contains='Ch').values('name', 'id')\nentries = Entry.objects.filter(blog__name__in=inner_qs)\ngtLink to this heading#Lebih besar dari
\nContoh:
\nEntry.objects.filter(id__gt=4)\nSQL setara:
\nSELECT ... WHERE id > 4;\ngteLink to this heading#Lebih besar dari atau sama dengan.
\nltLink to this heading#Kurang dari
\nlteLink to this heading#Kurang dari atau sama dengan.
\nstartswithLink to this heading#Case-sensitive starts-with.
\nContoh:
\nEntry.objects.filter(headline__startswith='Will')\nSQL setara:
\nSELECT ... WHERE headline LIKE 'Will%';\nSQLite doesn't support case-sensitive LIKE statements; startswith acts\nlike istartswith for SQLite.
istartswithLink to this heading#Case-insensitive starts-with.
\nContoh:
\nEntry.objects.filter(headline__istartswith='will')\nSQL setara:
\nSELECT ... WHERE headline ILIKE 'Will%';\nendswithLink to this heading#Case-sensitive ends-with.
\nContoh:
\nEntry.objects.filter(headline__endswith='cats')\nSQL setara:
\nSELECT ... WHERE headline LIKE '%cats';\niendswithLink to this heading#Case-insensitive ends-with.
\nContoh:
\nEntry.objects.filter(headline__iendswith='will')\nSQL setara:
\nSELECT ... WHERE headline ILIKE '%will'\nrangeLink to this heading#Range test (inclusive).
\nContoh:
\nimport datetime\nstart_date = datetime.date(2005, 1, 1)\nend_date = datetime.date(2005, 3, 31)\nEntry.objects.filter(pub_date__range=(start_date, end_date))\nSQL setara:
\nSELECT ... WHERE pub_date BETWEEN '2005-01-01' and '2005-03-31';\nYou can use range anywhere you can use BETWEEN in SQL — for dates,\nnumbers and even characters.
dateLink to this heading#For datetime fields, casts the value as date. Allows chaining additional field\nlookups. Takes a date value.
\nContoh:
\nEntry.objects.filter(pub_date__date=datetime.date(2005, 1, 1))\nEntry.objects.filter(pub_date__date__gt=datetime.date(2005, 1, 1))\n(No equivalent SQL code fragment is included for this lookup because\nimplementation of the relevant query varies among different database engines.)
\nWhen USE_TZ is True, fields are converted to the current time\nzone before filtering.
yearLink to this heading#For date and datetime fields, an exact year match. Allows chaining additional\nfield lookups. Takes an integer year.
\nContoh:
\nEntry.objects.filter(pub_date__year=2005)\nEntry.objects.filter(pub_date__year__gte=2005)\nSQL setara:
\nSELECT ... WHERE pub_date BETWEEN '2005-01-01' AND '2005-12-31';\nSELECT ... WHERE pub_date >= '2005-01-01';\n(The exact SQL syntax varies for each database engine.)
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering.
monthLink to this heading#For date and datetime fields, an exact month match. Allows chaining additional\nfield lookups. Takes an integer 1 (January) through 12 (December).
\nContoh:
\nEntry.objects.filter(pub_date__month=12)\nEntry.objects.filter(pub_date__month__gte=6)\nSQL setara:
\nSELECT ... WHERE EXTRACT('month' FROM pub_date) = '12';\nSELECT ... WHERE EXTRACT('month' FROM pub_date) >= '6';\n(The exact SQL syntax varies for each database engine.)
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
dayLink to this heading#For date and datetime fields, an exact day match. Allows chaining additional\nfield lookups. Takes an integer day.
\nContoh:
\nEntry.objects.filter(pub_date__day=3)\nEntry.objects.filter(pub_date__day__gte=3)\nSQL setara:
\nSELECT ... WHERE EXTRACT('day' FROM pub_date) = '3';\nSELECT ... WHERE EXTRACT('day' FROM pub_date) >= '3';\n(The exact SQL syntax varies for each database engine.)
\nNote this will match any record with a pub_date on the third day of the month,\nsuch as January 3, July 3, etc.
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
week_dayLink to this heading#For date and datetime fields, a 'day of the week' match. Allows chaining\nadditional field lookups.
\nTakes an integer value representing the day of week from 1 (Sunday) to 7\n(Saturday).
\nContoh:
\nEntry.objects.filter(pub_date__week_day=2)\nEntry.objects.filter(pub_date__week_day__gte=2)\n(No equivalent SQL code fragment is included for this lookup because\nimplementation of the relevant query varies among different database engines.)
\nNote this will match any record with a pub_date that falls on a Monday (day\n2 of the week), regardless of the month or year in which it occurs. Week days\nare indexed with day 1 being Sunday and day 7 being Saturday.
When USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
hourLink to this heading#For datetime and time fields, an exact hour match. Allows chaining additional\nfield lookups. Takes an integer between 0 and 23.
\nContoh:
\nEvent.objects.filter(timestamp__hour=23)\nEvent.objects.filter(time__hour=5)\nEvent.objects.filter(timestamp__hour__gte=12)\nSQL setara:
\nSELECT ... WHERE EXTRACT('hour' FROM timestamp) = '23';\nSELECT ... WHERE EXTRACT('hour' FROM time) = '5';\nSELECT ... WHERE EXTRACT('hour' FROM timestamp) >= '12';\n(The exact SQL syntax varies for each database engine.)
\nFor datetime fields, when USE_TZ is True, values are converted\nto the current time zone before filtering.
minuteLink to this heading#For datetime and time fields, an exact minute match. Allows chaining additional\nfield lookups. Takes an integer between 0 and 59.
\nContoh:
\nEvent.objects.filter(timestamp__minute=29)\nEvent.objects.filter(time__minute=46)\nEvent.objects.filter(timestamp__minute__gte=29)\nSQL setara:
\nSELECT ... WHERE EXTRACT('minute' FROM timestamp) = '29';\nSELECT ... WHERE EXTRACT('minute' FROM time) = '46';\nSELECT ... WHERE EXTRACT('minute' FROM timestamp) >= '29';\n(The exact SQL syntax varies for each database engine.)
\nFor datetime fields, When USE_TZ is True, values are converted\nto the current time zone before filtering.
secondLink to this heading#For datetime and time fields, an exact second match. Allows chaining additional\nfield lookups. Takes an integer between 0 and 59.
\nContoh:
\nEvent.objects.filter(timestamp__second=31)\nEvent.objects.filter(time__second=2)\nEvent.objects.filter(timestamp__second__gte=31)\nSQL setara:
\nSELECT ... WHERE EXTRACT('second' FROM timestamp) = '31';\nSELECT ... WHERE EXTRACT('second' FROM time) = '2';\nSELECT ... WHERE EXTRACT('second' FROM timestamp) >= '31';\n(The exact SQL syntax varies for each database engine.)
\nFor datetime fields, when USE_TZ is True, values are converted\nto the current time zone before filtering.
isnullLink to this heading#Takes either True or False, which correspond to SQL queries of\nIS NULL and IS NOT NULL, respectively.
Contoh:
\nEntry.objects.filter(pub_date__isnull=True)\nSQL setara:
\nSELECT ... WHERE pub_date IS NULL;\nsearchLink to this heading#A boolean full-text search, taking advantage of full-text indexing. This is\nlike contains but is significantly faster due to full-text indexing.
Contoh:
\nEntry.objects.filter(headline__search="+Django -jazz Python")\nSQL setara:
\nSELECT ... WHERE MATCH(tablename, headline) AGAINST (+Django -jazz Python IN BOOLEAN MODE);\nCatat ini hanya tersedia di MySQL dan membutuhkan manipulasi langsung dari basisdata untuk menambahkan indeks full-text. Secara awal Django menggunakan BOOLEAN MODE untuk pencarian teks penuh. Lihat MySQL documentation untuk tambahan rincian.
\nregexLink to this heading#Case-sensitive regular expression match.
\nThe regular expression syntax is that of the database backend in use.\nIn the case of SQLite, which has no built in regular expression support,\nthis feature is provided by a (Python) user-defined REGEXP function, and\nthe regular expression syntax is therefore that of Python's re module.
Contoh:
\nEntry.objects.get(title__regex=r'^(An?|The) +')\nSQL equivalents:
\nSELECT ... WHERE title REGEXP BINARY '^(An?|The) +'; -- MySQL\n\nSELECT ... WHERE REGEXP_LIKE(title, '^(An?|The) +', 'c'); -- Oracle\n\nSELECT ... WHERE title ~ '^(An?|The) +'; -- PostgreSQL\n\nSELECT ... WHERE title REGEXP '^(An?|The) +'; -- SQLite\nUsing raw strings (e.g., r'foo' instead of 'foo') for passing in the\nregular expression syntax is recommended.
iregexLink to this heading#Case-insensitive regular expression match.
\nContoh:
\nEntry.objects.get(title__iregex=r'^(an?|the) +')\nSQL equivalents:
\nSELECT ... WHERE title REGEXP '^(an?|the) +'; -- MySQL\n\nSELECT ... WHERE REGEXP_LIKE(title, '^(an?|the) +', 'i'); -- Oracle\n\nSELECT ... WHERE title ~* '^(an?|the) +'; -- PostgreSQL\n\nSELECT ... WHERE title REGEXP '(?i)^(an?|the) +'; -- SQLite\nDjango provides the following aggregation functions in the\ndjango.db.models module. For details on how to use these\naggregate functions, see the topic guide on aggregation. See the Aggregate\ndocumentation to learn how to create your aggregates.
All aggregates have the following parameters in common:
\nexpressionLink to this heading#A string that references a field on the model, or a query expression.
\noutput_fieldLink to this heading#An optional argument that represents the model field\nof the return value
\n\n**extraLink to this heading#Keyword arguments that can provide extra context for the SQL generated\nby the aggregate.
\nAvgLink to this heading#Returns the mean value of the given expression, which must be numeric\nunless you specify a different output_field.
Default alias: <field>__avg
Return type: float (or the type of whatever output_field is\nspecified)
CountLink to this heading#Returns the number of objects that are related through the provided\nexpression.
\nDefault alias: <field>__count
Jenis kembalian: int
Mempunyai satu argumen pilihan:
\nIf distinct=True, the count will only include unique instances.\nThis is the SQL equivalent of COUNT(DISTINCT <field>). The default\nvalue is False.
MaxLink to this heading#Returns the maximum value of the given expression.
\nDefault alias: <field>__max
Return type: same as input field, or output_field if supplied
MinLink to this heading#Returns the minimum value of the given expression.
\nDefault alias: <field>__min
Return type: same as input field, or output_field if supplied
StdDevLink to this heading#Returns the standard deviation of the data in the provided expression.
\nDefault alias: <field>__stddev
Jenis kembalian: float
Mempunyai satu argumen pilihan:
\nBy default, StdDev returns the population standard deviation. However,\nif sample=True, the return value will be the sample standard deviation.
SumLink to this heading#Computes the sum of all values of the given expression.
\nDefault alias: <field>__sum
Return type: same as input field, or output_field if supplied
VarianceLink to this heading#Returns the variance of the data in the provided expression.
\nDefault alias: <field>__variance
Jenis kembalian: float
Mempunyai satu argumen pilihan:
\nBy default, Variance returns the population variance. However,\nif sample=True, the return value will be the sample variance.