QuerySetLink 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.
\nQuerySet dinilaiLink 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.
Anda dapat menilai QuerySet dalam cara berikut:
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.
Basisdata yang akan digunakan jika permintaan ini dijalankan sekarang.
\nQuerySet baruLink 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 (*args).
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'\nCatat bahwa contoh kedua lebih bersifat membatasi.
\nIf you need to execute more complex queries (for example, queries with OR statements),\nyou can use Q objects (*args).
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.
\nalias()Link to this heading#Same as annotate(), but instead of annotating objects in the\nQuerySet, saves the expression for later reuse with other QuerySet\nmethods. This is useful when the result of the expression itself is not needed\nbut it is used for filtering, ordering, or as a part of a complex expression.\nNot selecting the unused value removes redundant work from the database which\nshould result in better performance.
For example, if you want to find blogs with more than 5 entries, but are not\ninterested in the exact number of entries, you could do this:
\n>>> from django.db.models import Count\n>>> blogs = Blog.objects.alias(entries=Count('entry')).filter(entries__gt=5)\nalias() can be used in conjunction with annotate(), exclude(),\nfilter(), order_by(), and update(). To use aliased expression\nwith other methods (e.g. aggregate()), you must promote it to an\nannotation:
Blog.objects.alias(entries=Count('entry')).annotate(\n entries=F('entries'),\n).aggregate(Sum('entries'))\nfilter() and order_by() can take expressions directly, but\nexpression construction and usage often does not happen in the same place (for\nexample, QuerySet method creates expressions, for later use in views).\nalias() allows building complex expressions incrementally, possibly\nspanning multiple methods and modules, refer to the expression parts by their\naliases and only use annotate() for the final result.
order_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('?')\nCatatan: permintaan order_by('?') mungkin mahal dan lambat, bergantung pada backend basisdata anda sedang gunakan.
Untuk mengurutkan berdasarkan sebuah bidang dalam sebuah model berbeda, gunakan sintaksis sama ketika anda sedang meminta lintas hubungan model. Yaitu, nama dari bidang, diikuti oleh garis bawah ganda (__), diikuti oleh nama dalam model baru, dan seterusnya untuk sebanyak model anda ingin gabungkan. Sebagai contoh:
Entry.objects.order_by('blog__name', 'headline')\nJika anda mencoba mengurutkan berdasarkan sebuah bidang yang hubungan ke model lain, Django akan menggunakan pengurutan awalan pada model terkait, atau diurutkan berdasarkan primary key model terkait jika tidak ada Meta.ordering ditentukan. Sebagai contoh, sejak model Blog tidak mempunyau pengurutan awalan ditentukan:
Entry.objects.order_by('blog')\n... mirip ke:
\nEntry.objects.order_by('blog__id')\nJika Blog mempunyai ordering = ['name'], kemudian himpunan permintaan pertama akan mirip pada:
Entry.objects.order_by('blog__name')\nYou can also order by query expressions by\ncalling asc() or desc() on the\nexpression:
Entry.objects.order_by(Coalesce('summary', 'headline').desc())\nasc() dan desc() mempunyai argumen (nulls_first dan nulls_last) yang mengendalikan bagimana nilai-nilai null diurutkan.
Waspadalah ketika mengurutkan berdasarkan bidang-bidang dalam model terkait jika anda juga menggunakan distinct(). Lihat catatan dalam distinct() untuk sebuah penjelasan dari bagaimana pengurutan model terkait dapat merubah hasil diharapkan.
Tidak ada cara menentukan apakah pengurutan harus kasus peka. Sehubungan dengan kasus-kepekaan, Django akan mengurutkan hasil bagaimanapun backend basisdata anda biasanya mengurutkan mereka.
\nAnda dapat mengurutkan berdasarkan sebuah bidang dirubah menjadi huruf kecil dengan Lower yang akan mencapai pengurutan kasus-tetap:
Entry.objects.order_by(Lower('headline').desc())\nJika anda tidak ingin pengurutan apapun diberlakukan pada permintaan, bahkan tidak pada pengurutan awalan, panggil order_by() tanpa parameter.
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.
Setiap panggilan order_by() akan membersihkan urutan sebelumnya. Sebagai contoh, permintaan ini akan diurutkan berdasarkan pub_date dan bukan 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.
Untuk mengambil lima abrang "terakhir" dalam himpunan permintaan, anda dapat melakukan ini:
\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.
Contoh-contoh (setelah itu pertama hanya akan bekerja pada 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.
\nContoh ini membandingkan kamus-kamus dari values() dengan obyek model biasa:
# 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'}]>\nThe values() method also takes optional keyword arguments,\n**expressions, which are passed through to annotate():
>>> from django.db.models.functions import Lower\n>>> Blog.objects.values(lower_name=Lower('name'))\n<QuerySet [{'lower_name': 'beatles blog'}]>\nYou can use built-in and custom lookups in\nordering. For example:
\n>>> from django.db.models import CharField\n>>> from django.db.models.functions import Lower\n>>> CharField.register_lookup(Lower)\n>>> Blog.objects.values('name__lower')\n<QuerySet [{'name__lower': 'beatles blog'}]>\nAn aggregate within a values() clause is applied before other arguments\nwithin the same values() clause. If you need to group by another value,\nadd it to an earlier values() clause instead. For example:
>>> from django.db.models import Count\n>>> Blog.objects.values('entry__authors', entries=Count('entry'))\n<QuerySet [{'entry__authors': 1, 'entries': 20}, {'entry__authors': 1, 'entries': 13}]>\n>>> Blog.objects.values('entry__authors').annotate(entries=Count('entry'))\n<QuerySet [{'entry__authors': 1, 'entries': 33}]>\nSedikit kebijakan yang berharga disebutkan:
\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 TypeError.
Combining transforms and aggregates requires the use of two annotate()\ncalls, either explicitly or as keyword arguments to values(). As above,\nif the transform has been registered on the relevant field type the first\nannotate() can be omitted, thus the following examples are equivalent:
>>> from django.db.models import CharField, Count\n>>> from django.db.models.functions import Lower\n>>> CharField.register_lookup(Lower)\n>>> Blog.objects.values('entry__authors__name__lower').annotate(entries=Count('entry'))\n<QuerySet [{'entry__authors__name__lower': 'test author', 'entries': 33}]>\n>>> Blog.objects.values(\n... entry__authors__name__lower=Lower('entry__authors__name')\n... ).annotate(entries=Count('entry'))\n<QuerySet [{'entry__authors__name__lower': 'test author', 'entries': 33}]>\n>>> Blog.objects.annotate(\n... entry__authors__name__lower=Lower('entry__authors__name')\n... ).values('entry__authors__name__lower').annotate(entries=Count('entry'))\n<QuerySet [{'entry__authors__name__lower': 'test author', 'entries': 33}]>\nIt 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 or expression passed into the values_list() call — so the\nfirst item is the first field, etc. For example:
>>> Entry.objects.values_list('id', 'headline')\n<QuerySet [(1, 'First entry'), ...]>\n>>> from django.db.models.functions import Lower\n>>> Entry.objects.values_list('id', Lower('headline'))\n<QuerySet [(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<QuerySet[(1,), (2,), (3,), ...]>\n\n>>> Entry.objects.values_list('id', flat=True).order_by('id')\n<QuerySet [1, 2, 3, ...]>\nItu adalah sebuah kesalahan melewatkan dalam flat ketika ada lebih dari satu bidang.
You can pass named=True to get results as a\nnamedtuple():
>>> Entry.objects.values_list('id', 'headline', named=True)\n<QuerySet [Row(id=1, headline='First entry'), ...]>\nUsing a named tuple may make use of the results more readable, at the expense\nof a small performance penalty for transforming the results into a named tuple.
\nJika anda tidak melewatkan nilai apapun ke values_list(), itu akan mengembalikan semua bidang dalam model, dalam urutan mereka dinyatakan.
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<QuerySet [('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<QuerySet [('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", "week", or "day".\nEach datetime.date object in the result list is "truncated" to the\ngiven type.
"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.
"week" returns a list of all distinct year/week values for the field. All\ndates will be a Monday.
"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.
Contoh:
\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', 'week')\n[datetime.date(2005, 2, 14), datetime.date(2005, 3, 14)]\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 harus berupa nama dari DateTimeField model anda.
kind should be either "year", "month", "week", "day",\n"hour", "minute", or "second". Each datetime.datetime\nobject in the result list 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.
is_dst indicates whether or not pytz should interpret nonexistent and\nambiguous datetimes in daylight saving time. By default (when is_dst=None),\npytz raises an exception for such datetimes.
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.
Contoh:
\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.
union()Link to this heading#Uses SQL's UNION operator to combine the results of two or more\nQuerySets. For example:
>>> qs1.union(qs2, qs3)\nThe UNION operator selects only distinct values by default. To allow\nduplicate values, use the all=True argument.
union(), intersection(), and difference() return model instances\nof the type of the first QuerySet even if the arguments are QuerySets\nof other models. Passing different models works as long as the SELECT list\nis the same in all QuerySets (at least the types, the names don't matter\nas long as the types are in the same order). In such cases, you must use the\ncolumn names from the first QuerySet in QuerySet methods applied to the\nresulting QuerySet. For example:
>>> qs1 = Author.objects.values_list('name')\n>>> qs2 = Entry.objects.values_list('headline')\n>>> qs1.union(qs2).order_by('name')\nIn addition, only LIMIT, OFFSET, COUNT(*), ORDER BY, and\nspecifying columns (i.e. slicing, count(), exists(),\norder_by(), and values()/values_list()) are allowed\non the resulting QuerySet. Further, databases place restrictions on\nwhat operations are allowed in the combined queries. For example, most\ndatabases don't allow LIMIT or OFFSET in the combined queries.
intersection()Link to this heading#Uses SQL's INTERSECT operator to return the shared elements of two or more\nQuerySets. For example:
>>> qs1.intersection(qs2, qs3)\nLihat union() untuk beberapa pembatasan.
difference()Link to this heading#Uses SQL's EXCEPT operator to keep only elements present in the\nQuerySet but not in some other QuerySets. For example:
>>> qs1.difference(qs2, qs3)\nLihat union() untuk beberapa pembatasan.
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.
Berdasarkan pengertian, pencarian tambahan ini mungkin tidak dapat di hubungkan pada mesin basisdata lain (karena anda secara tegas menulis kode SQL) dan melanggar prinsip DRY, jadi anda harus menghindari mereka jika memungkinkan.
\nTentukan satu atau lebih dari params, select, where atau tables. Tidak satupun dari argumen dibutuhkan, tetapi anda harus menggunakan setidaknya satu dari mereka.
select
Argumen select membiarkan anda menaruh bidang tambahan dalam klausa SELECT. Itu harus berupa nama-nama atribut pemetaan sebuah dictionary pada SQL untuk digunakan menghitung atribut itu.
Contoh:
\nEntry.objects.extra(select={'is_recent': "pub_date > '2006-01-01'"})\nSebagai hasil, setiap obyek Entry masukan mempunyai satu atribut tambahan, is_recent, sebuah boolean mewakili apakah pub_date masukan lebih besar dari 1 Januari 2006.
Django inserts the given SQL snippet directly into the SELECT\nstatement, so the resulting SQL of the above example would be something like:
SELECT blog_entry.*, (pub_date > '2006-01-01') AS is_recent\nFROM blog_entry;\nContoh selanjutnya lebih tinggi; itu melakukan subpermintaan untuk memberikan setiap obyek Blog hasil sebuah atribut entry_count, sebuah hitungan integer dari obyek Entry terkait .
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.
Ini akan bekerja, sebagai contoh:
\nBlog.objects.extra(\n select={'a': '%s', 'b': '%s'},\n select_params=('one', 'two'),\n)\nJika anda butuh menggunakan sebuah harfiah %s didalam string terpilih anda, gunakan urutan %%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')\nBerhati-hatilan ketika menggunakan parameter tables jika anda sedang menentukan tabel-tabel yang sudah digunakan dalam permintaan. Ketika anda menambahkan tabel-tabel tambahan melalui parameter table, Django beranggapan anda ingin bahwa tabel disertakan sebuah waktu tambahan, jika itu sudah disertakan. itu membuat sebuah masalah, sejak nama tabel akan kemudian diberikan sebuah nama lain. Jika sebuah tabel muncul berulang kali dalam sebuah pernyataan SQL, kejadian kedua dan seterusnya harus menggunakan nama lain sehingga basisdata dapat membedakan mereka. Jika anda sedang mengacu pada tabel tambahan anda telah tambahkan dalam parameter where tambahan ini akan menyebabkan kesalahan-kesalahan.
Secara biasa anda hanya butuh menambahkan tabel tambahan yang belum muncul dalam permintaan. Bagaimanapun, jika kasus diuraikan diatas tidak muncul, ada sedikit pemecahan. Pertama, lihat jika anda dapat mendapatkan dengan tanpa menyertakan tabel tambahan dan menggunakan satu yang sudah ada di dalam permintaan. Jika itu tidak memungkinkan, taruh panggilan extra() anda pada depan dari pembangunan queryset sehingga tabel anda adalah penggunaan pertama dari tabel itu. Akhirnya, jika semuanya gagal, cari permintaan dihasilkan dan tulis kembali tambahan where anda untuk menggunakan nama lain diberikan pada tabel tambahan anda. nama lain akan sama setiap kali anda membangun queryset dalam cara sama, jadi anda dapat bergantung pada nama lain untuk tidak berubah.
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#Dalam beberapa keadaan permodelan-data rumit, model anda mungkin mengandung banyak bidang, beberapa diantaranya dapat mengandung banyak data (sebagai contoh, bidang teks), atau mewajibkan pengolahan mahal untuk merubah mereka jadi obyek Python. Jika anda sedang menggunakan hasil dari queryset dalam beberapa keadaan dimana anda tidak mengetahui jika bidang-bidang tertentu tersebut ketika anda menginisialisasikan mengambil data, anda dapat memberitahu Django tidak mengambil mereka dari basisdata.
\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).
\nAnda dapat membuat panggilan banyak pada defer(). Setiap panggilan menambahkan bidang baru ke kumpulan yang ditangguhkan:
# 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")\nJika anda ingin membersihkan kumpulan dari bidang-bidang yang ditunda, lewatkan None sebagai sebuah parameter pada deferr().
# Load all fields immediately.\nmy_queryset.defer(None)\nBeberapa bidang dalam sebuah model tidak aakan ditunda, bahkan jika anda meminta mereka. Anda tidak pernah dapat menunda memuat primary key. Jika anda sedang menggunakan select_related() mengambil model terkait, anda tidak harus memunda dari bidang yang terhubung ke model utama ke satu terkait, melakukannya akan menghasilkan dalam sebuah kesalahan.
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.
Menggunakan only() dan memancarkan sebuah bidang diminta menggunakan select_related() adalah sebuah kesalahan juga.
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:
\nfrom django.db import transaction\n\nentries = Entry.objects.select_for_update().filter(author=request.user)\nwith transaction.atomic():\n for entry in entries:\n ...\nWhen the queryset is evaluated (for entry in entries in this case), all\nmatched entries will be locked until the end of the transaction block, meaning\nthat other transactions will be prevented from changing or acquiring locks on\nthem.
Usually, 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. You can also ignore locked rows by using\nselect_for_update(skip_locked=True) instead. The nowait and\nskip_locked are mutually exclusive and attempts to call\nselect_for_update() with both options enabled will result in a\nValueError.
By default, select_for_update() locks all rows that are selected by the\nquery. For example, rows of related objects specified in select_related()\nare locked in addition to rows of the queryset's model. If this isn't desired,\nspecify the related objects you want to lock in select_for_update(of=(...))\nusing the same fields syntax as select_related(). Use the value 'self'\nto refer to the queryset's model.
On PostgreSQL only, you can pass no_key=True in order to acquire a weaker\nlock, that still allows creating rows that merely reference locked rows\n(through a foreign key, for example) while the lock is in place. The\nPostgreSQL documentation has more details about row-level lock modes.
Anda tidak dapat menggunakan select_for_update() pada hubungan null:
>>> Person.objects.select_related('hometown').select_for_update()\nTraceback (most recent call last):\n...\ndjango.db.utils.NotSupportedError: FOR UPDATE cannot be applied to the nullable side of an outer join\nUntuk menghindari pembatasan, anda dapat tidak menyertakan obyek null jika anda tidak peduli dengan mereka:
\n>>> Person.objects.select_related('hometown').select_for_update().exclude(hometown=None)\n<QuerySet [<Person: ...)>, ...]>\nCurrently, the postgresql, oracle, and mysql database\nbackends support select_for_update(). However, MariaDB 10.3+ supports only\nthe nowait argument and MySQL 8.0.1+ supports the nowait,\nskip_locked, and of arguments. The no_key argument is supported\nonly on PostgreSQL.
Passing nowait=True, skip_locked=True, no_key=True, or of to\nselect_for_update() using database backends that do not support these\noptions, such as MySQL, raises a NotSupportedError. This\nprevents code from unexpectedly blocking.
Menilai sebuah queryset dengan select_for_update() dalam suasana autocommit pada backend yang mendukung SELECT ... FOR UPDATE adalah sebuah kesalahan TransactionManagementError karena baris-baris tidak dikunci dalam kasus itu. jiak diizinkan, ini akan memfasilitasi kerusakan data dan dapat dengan mudah disebabkan oleh memanggil kode yang mengharapkan dijalankan dalam sebuah transaksi diluar dari satu.
Menggunakan select_for_update() pada backend yang tidak mendukung SELECT ... FOR UPDATE (seperti SQLite) tidak akan mempunyai pengaruh. SELECT ... FOR UPDATE tidak akan ditambahkan pada permintaan, dan sebuah kesalahan tidak dimunculkan jika select_for_update() digunakan dalam suasana autocommit.
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 a normal QuerySet to provide object\ninstances.
Lihat Melakukan permintaan SQL mentah untuk informasi lebih.
\n\n\nQueryset paduan harus menggunakan model sama.
\n&)Link to this heading#Memadukan dua QuerySet menggunakan penghubung AND SQL.
Berikut adalah setara:
\nModel.objects.filter(x=1) & Model.objects.filter(y=2)\nModel.objects.filter(x=1, y=2)\nfrom django.db.models import Q\nModel.objects.filter(Q(x=1) & Q(y=2))\nSetara SQL:
\nSELECT ... WHERE x=1 AND y=2\n|)Link to this heading#Memadukan dua QuerySet menggunakan penghubung OR SQL.
Berikut adalah setara:
\nModel.objects.filter(x=1) | Model.objects.filter(y=2)\nfrom django.db.models import Q\nModel.objects.filter(Q(x=1) | Q(y=2))\nSetara SQL:
\nSELECT ... WHERE x=1 OR y=2\nQuerySetLink to this heading#Metode QuerySet berikut menilai QuerySet dan mengembalikan sesuatu selain dari QuerySet.
Metode-metode ini tidak menggunakan penyimpanan sementara (lihat Cache dan QuerySet). Daripada, mereka meminta basisdata setiap kali mereka dipanggil.
\nget()Link to this heading#Returns the object matching the given lookup parameters, which should be in\nthe format described in Field lookups. You should use lookups that are\nguaranteed unique, such as the primary key or fields in a unique constraint.\nFor example:
\nEntry.objects.get(id=1)\nEntry.objects.get(Q(blog=blog) & Q(entry_number=1))\nIf you expect a queryset to already return one row, you can use get()\nwithout any arguments to return the object for that row:
Entry.objects.filter(pk=1).get()\nIf get() doesn't find any object, it raises a Model.DoesNotExist exception:
Entry.objects.get(id=-999) # raises Entry.DoesNotExist\nIf get() finds more than one object, it raises a\nModel.MultipleObjectsReturned exception:
Entry.objects.get(name='A Duplicated Name') # raises Entry.MultipleObjectsReturned\nBoth these exception classes are attributes of the model class, and specific to\nthat model. If you want to handle such exceptions from several get() calls\nfor different models, you can use their generic base classes. For example, you\ncan use django.core.exceptions.ObjectDoesNotExist to handle\nDoesNotExist exceptions from multiple models:
from django.core.exceptions import ObjectDoesNotExist\n\ntry:\n blog = Blog.objects.get(id=1)\n entry = Entry.objects.get(blog=blog, entry_number=1)\nexcept ObjectDoesNotExist:\n print("Either the blog or entry doesn't exist.")\ncreate()Link to this heading#Sebuah metode nyaman untuk membuat sebuah obyek dan menyimpan itu semua dalam satu langkah. Jadi:
\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.
\nParameter force_insert didokumentasikan ditempat lain, tetapi semua itu berarti bahwa sebuah obyek baru akan selalu dibuat. Biasanya anda tidak akan perlu khawatir tentang ini. Bagaimanapun, jika model anda mengandung nilai primary key maual yang anda setel dan jika nilai itu sudah ada dalam basisdata, panggilan pada create() akan gagal denga sebuah IntegrityError karena primary key harus unik. Bersiaplah untuk menangani pengecualian jika anda sedang menggunakan primary keys manual.
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.
Mengembalikan sebuah tuple dari (object, created), dimana object adalah obyek diambil atau dibuat adalah sebuah boolean menentukan apakah sebuah obyek baru telah dibuat.
This is meant to prevent duplicate objects from being created when requests are\nmade in parallel, and 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()\nHere, with concurrent requests, multiple attempts to save a Person with\nthe same parameters may be made. To avoid this race condition, the above\nexample 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)\nKatakunci argumen apapun dilewatkan ke get_or_create() — kecuali sebuah pilihan dipanggil defaults — akan digunakan dalam panggilan get(). Jika sebuah obyek ditemukan, get_or_create() mengembalikan sebuah tuple dari obyek itu dan False.
You can specify more complex conditions for the retrieved object by chaining\nget_or_create() with filter() and using Q objects. For example, to retrieve Robert or Bob Marley if either\nexists, and create the latter otherwise:
from django.db.models import Q\n\nobj, created = Person.objects.filter(\n Q(first_name='Bob') | Q(first_name='Robert'),\n).get_or_create(last_name='Marley', defaults={'first_name': 'Bob'})\nIf multiple 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({k: v() if callable(v) else v for k, v in defaults.items()})\nobj = self.model(**params)\nobj.save()\nDalam Bahasa Inggris, itu berarti dimulai dengan apapun argumen kata kunci non-'defaults' yang tidak mengandung garis bawah ganda (yang akan menunjukkan sebuah pencarian bukan-persis). Kemudian tambah isi dari defaults, menimpa kunci apapun jika diperlukan, dan gunakan hasil sebagai argumen kata kunci pada kelas model. Jika ada callabke apapun dalam defaults, nilai mereka. Seperti ditunjukkan diatas, ini adalah penyerderhanaan dari algoritma yang digunakan, tetapi itu mengandung semua rincian bersangkutan. Penerapan internal mempunyai beberapa lebih pemeriksanaan-kesalahan daripada ini dan menangani beberapa kondisi-tepi tambahan; jik anda tertarik, baca kode.
If you have a field named defaults and want to use it as an exact lookup in\nget_or_create(), 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.
Akhirnya, sebuah kata pada penggunakan get_or_create() dalam tampilan Django. Harap pastikan untuk menggunakan itu hanya dalam permintaan POST meskipun anda mempunyai alasan bagus untuk tidak. Permintaan GET tidak harus mempunyai pengaruh pada. Daripada, gunakan POSt kapanpun sebuah permintaan pada sebuah halaman mempunyai pengaruh samping pada data anda. Untuk lebih, lihat Safe methods dalam spesifikasi HTTP.
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. The values in defaults can be callables.
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 a detailed description of 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.
Like get_or_create() and create(), if you're using manually\nspecified primary keys and an object needs to be created but the key already\nexists in the database, an IntegrityError is raised.
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), and returns created objects as a list, in the same order as provided:
\n>>> objs = Entry.objects.bulk_create([\n... Entry(headline='This is a test'),\n... Entry(headline='This is only a test'),\n... ])\nIni mempunyai sejumlah peringatan:
\nMetode save() model tidak akan dipanggil, dan sinyal pre_save dan post_save tidak akan dikirim.
Itu tidak bekerja dengan anak model dalam sebuah skenario warisan banyak-tabel.
If the model's primary key is an AutoField, the\nprimary key attribute can only be retrieved on certain databases (currently\nPostgreSQL and MariaDB 10.5+). On other databases, it will not be set.
Itu tidak bekerja dengan hubungan many-to-many.
It casts objs to a list, which fully evaluates objs if it's a\ngenerator. The cast allows inspecting all objects so that any objects with a\nmanually set primary key can be inserted first. If you want to insert objects\nin batches without evaluating the entire generator at once, you can use this\ntechnique as long as the objects don't have any manually set primary keys:
from itertools import islice\n\nbatch_size = 100\nobjs = (Entry(headline='Test %s' % i) for i in range(1000))\nwhile True:\n batch = list(islice(objs, batch_size))\n if not batch:\n break\n Entry.objects.bulk_create(batch, batch_size)\nThe batch_size parameter controls how many objects are created in a 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.
On databases that support it (all but Oracle), setting the ignore_conflicts\nparameter to True tells the database to ignore failure to insert any rows\nthat fail constraints such as duplicate unique values. Enabling this parameter\ndisables setting the primary key on each model instance (if the database\nnormally supports it).
bulk_update()Link to this heading#This method efficiently updates the given fields on the provided model\ninstances, generally with one query:
\n>>> objs = [\n... Entry.objects.create(headline='Entry 1'),\n... Entry.objects.create(headline='Entry 2'),\n... ]\n>>> objs[0].headline = 'This is entry 1'\n>>> objs[1].headline = 'This is entry 2'\n>>> Entry.objects.bulk_update(objs, ['headline'])\nQuerySet.update() is used to save the changes, so this is more efficient\nthan iterating through the list of models and calling save() on each of\nthem, but it has a few caveats:
Anda tidak dapat memperbaharui primary key model.
Each model's save() method isn't called, and the\npre_save and\npost_save signals aren't sent.
If updating a large number of columns in a large number of rows, the SQL\ngenerated can be very large. Avoid this by specifying a suitable\nbatch_size.
Updating fields defined on multi-table inheritance ancestors will incur an\nextra query per ancestor.
When an individual batch contains duplicates, only the first instance in that\nbatch will result in an update.
The batch_size parameter controls how many objects are saved in a single\nquery. The default is to update all objects in one batch, except for SQLite\nand Oracle which have restrictions on the number of variables used in a query.
count()Link to this heading#Mengembalikan sebuah integer mewakili sejumlah obyek dalam QuerySet pencocokan basisdata.
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).
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.
If the queryset has already been fully retrieved, count() will use that\nlength rather than perform an extra database query.
in_bulk()Link to this heading#Takes a list of field values (id_list) and the field_name for those\nvalues, and returns a dictionary mapping each value to an instance of the\nobject with the given field value. No\ndjango.core.exceptions.ObjectDoesNotExist exceptions will ever be raised\nby in_bulk; that is, any id_list value not matching any instance will\nsimply be ignored. If id_list isn't provided, all objects\nin the queryset are returned. field_name must be a unique field or a\ndistinct field (if there's only one field specified in distinct()).\nfield_name defaults to the primary key.
Contoh:
\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>}\n>>> Blog.objects.in_bulk(['beatles_blog'], field_name='slug')\n{'beatles_blog': <Blog: Beatles Blog>}\n>>> Blog.objects.distinct('name').in_bulk(field_name='name')\n{'Beatles Blog': <Blog: Beatles Blog>, 'Cheddar Talk': <Blog: Cheddar Talk>, 'Django Weblog': <Blog: Django Weblog>}\nJika anda melewatkan in_bulk() sebuah daftar kosong, anda akan mendapatkan kamus kosong.
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.
Catat bahwa menggunakan iterator() pada sebuah QuerySet yang sudah dinilai akan memaksa itu dinilai kembali, mengulangi permintaan.
Juga, penggunaan iterator() menyebabkan panggilan prefetch_related() sebelumnya dapat diabaikan sejak dua optimalisasi ini tidak masuk akan bersama-sama.
Bergantung pada backend basisdata, hasil permintaan akan salah satu dimuat semua sekali atau dialirkan dari basisdata menggunakan kursor sisi-peladen.
\nOracle dan PostgreSQL menggunakan kursor sisi peladen untuk mengalirkan hasil dari basisdata tanpa memuat keseluruhan hasil disetel kedalam memori.
\nDriver basisdata Oracle selalu menggunakan jarum sisi-peladen.
\nWith server-side cursors, the chunk_size parameter specifies the number of\nresults to cache at the database driver level. Fetching bigger chunks\ndiminishes the number of round trips between the database driver and the\ndatabase, at the expense of memory.
On PostgreSQL, server-side cursors will only be used when the\nDISABLE_SERVER_SIDE_CURSORS\nsetting is False. Read Menggabungkan transaksi dan kursor sisi-peladen if\nyou're using a connection pooler configured in transaction pooling mode. When\nserver-side cursors are disabled, the behavior is the same as databases that\ndon't support server-side cursors.
MySQL doesn't support streaming results, hence the Python database driver loads\nthe entire result set into memory. The result set is then transformed into\nPython row objects by the database adapter using the fetchmany() method\ndefined in PEP 249.
SQLite can fetch results in batches using fetchmany(), but since SQLite\ndoesn't provide isolation between queries within a connection, be careful when\nwriting to the table being iterated over. See Pengucilan ketika menggunakan QuerySet.iterator() for\nmore information.
The chunk_size parameter controls the size of batches Django retrieves from\nthe database driver. Larger batches decrease the overhead of communicating with\nthe database driver at the expense of a slight increase in memory consumption.
Nilai awalan dari chunk_size, 2000, datang dari a calculation on the psycopg mailing list:
\n\nAssuming rows of 10-20 columns with a mix of textual and numeric data, 2000\nis going to fetch less than 100KB of data, which seems a good compromise\nbetween the number of rows transferred and the data discarded if the loop\nis exited early.
\n
latest()Link to this heading#Mengembalikan obyek terakhir dalam tabel berdasarkan pada bidang-bidang diberikan.
\nContoh ini mengembalikan Entry terakhir dalam tabel, menurut pada bidang pub-date:
Entry.objects.latest('pub_date')\nAnda dapat juga memilih terakhir berdasarkan pada beberapa bidang. Sebagai contoh, memilih Entry dengan expire_date paling awal ketika dua masukan memiliki pub_date sama:
Entry.objects.latest('pub_date', '-expire_date')\nTanda negatif dalam '-expire_date' berarti mengurutkan expire_date dalam urutan menurun. Karena latest() mendapatkan hasil terakhir, Entry dengan expire_date paling awal yang dipilih.
If your model's Meta specifies\nget_latest_by, you can omit any arguments to\nearliest() or latest(). The fields specified in\nget_latest_by will be used by default.
Seperti get(), earliest() dan latest() memunculkan DoesNotExist jika tidak ada obyek dengan parameter yang diberikan.
Catat bahwa adanya earliest() dan latest() semata-mata untuk kenyamanan dan mudahan membaca.
earliest()Link to this heading#Bekerja sebalinya seperti latest() kecuali arah dirubah.
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. This can affect\naggregation results as described in Interaksi dengan order_by().
Contoh:
\np = Article.objects.order_by('title', 'pub_date').first()\ncatat bahwa first() adalah metode nyaman, contoh kode berikut adalah setara pada contoh diatas:
try:\n p = Article.objects.order_by('title', 'pub_date')[0]\nexcept IndexError:\n p = None\nlast()Link to this heading#Bekerja seperti first(), tetapi mengembalikan obyek terakhir dalam 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.
\nSebagai contoh, ketika anda sedang bekerja dengan masukan blog, anda mungkin ingin mengetahui sejumlah penulis yang memiliki sumbangan masukan blog:
\n>>> from django.db.models import Count\n>>> q = Blog.objects.aggregate(Count('entry'))\n{'entry__count': 16}\nDengan menggunakan argumen kata kunci untuk menentukan fungsi pengumpulan, anda dapat mengendalikan nama dari nilai pengumpulan yang dikembalikan:
\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.
Metode paling efesien dari menemukan apakah sebuah model dengan bidang unik (misalnya primary_key) adalah anggota dari QuerySet adalah:
entry = Entry.objects.get(pk=123)\nif some_queryset.filter(pk=entry.pk).exists():\n print("Entry contained in queryset")\nYang akan lebih cepat daripada berikut yang membuatuhlan penilaian dan perulangan melalui seluruh queryset:
\nif entry in some_queryset:\n print("Entry contained in QuerySet")\nDan untuk menemukan apakah queryset mengandung barang apapun:
\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... tetapi bukan berdasarkan tingkatan besar (karena itu dibtuuhkan himpunan permintaan besar untuk mendapatkan efisiensi).
\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 using bool(some_queryset), which retrieves the\nresults 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).
\nSebagai contoh, untuk mematikan komentar untuk semua masukan blog diterbitkan dalam 2010, anda dapat melakukan ini:
\n>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False)\n(Ini menganggap model Entry mempunyai bidang pub_date dan comments_on.)
Anda dapat memperbaharui banyak bidang -- tidak ada batasan pada sbeerapa banyak. Sebagai contoh, disini kami memperbaharui bidang-bidang comments_on dan headline.
>>> 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!\nPenyaringan berdasarkan pada bidang terkait masuk mungkin, meskipun:
\n>>> Entry.objects.filter(blog__id=1).update(comments_on=True)\nAnda tidak dapat memanggil update() pada QuerySet yang mempunyai potongan diambil atau dapat sebalinya tidak lagi disaring.
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().
Akhirnya, sadari bahwa update() melakukan sebuah pembaharuan pada tingkat SQL dan, dengan demikian, tidak memanggil metode save() apapun pada model anda, tidak juga itu mengeluarkan sinyal pre_save atau post_save (yang merupakan konsekuensi dari memanggil Model.save()). Jiak anda ingin memperbaharui segerombol rekaman untuk model yang memmpunyai metode save() penyesuaian, ulangi terhadap mereka dan panggil save(), seperti ini:
for e in Entry.objects.filter(pub_date__year=2010):\n e.comments_on = False\n e.save()\nChaining order_by() with update() is supported only on MariaDB and\nMySQL, and is ignored for different databases. This is useful for updating a\nunique field in the order that is specified without conflicts. For example:
Entry.objects.order_by('-number').update(number=F('number') + 1)\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.
delete() diberlakukan cepat. Anda tidak dapat memanggil delete() pada sebuah QuerySet yang mempunyai potongan diambil atau dapat sebaliknya tidak lagi disaring.
Sebagai contoh, untuk menghapus semua masukan dalam blog tertentu:
\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.
Catat bahwa permintaan dibangkitkan dalam penghapusan obyek adalah sebuah subyek rincian penerapan untuk merubah.
\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.
explain()Link to this heading#Returns a string of the QuerySet’s execution plan, which details how the\ndatabase would execute the query, including any indexes or joins that would be\nused. Knowing these details may help you improve the performance of slow\nqueries.
Sebagai contoh, ketika menggunakan PostgreSQL:
\n>>> print(Blog.objects.filter(title='My Blog').explain())\nSeq Scan on blog (cost=0.00..35.50 rows=10 width=12)\n Filter: (title = 'My Blog'::bpchar)\nKeluaran berbeda secara penting diantara dua basisdata.
\nexplain() didukung oleh semua backend basisdata siap-pakai kecuali oracle karena sebuah penerapan tidak ada langsung.
The format parameter changes the output format from the databases's\ndefault, which is usually text-based. PostgreSQL supports 'TEXT',\n'JSON', 'YAML', and 'XML' formats. MariaDB and MySQL support\n'TEXT' (also called 'TRADITIONAL') and 'JSON' formats. MySQL\n8.0.16+ also supports an improved 'TREE' format, which is similar to\nPostgreSQL's 'TEXT' output and is used by default, if supported.
Beberapa basisdata menerima bendera yang dapat mengembalikan informasi lebih tentang permintaan. Lewatkan bendera-bendera ini sebagai argumen kata kunci. Sebagai contoh, ketika menggunakan PostgreSQL:
\n>>> print(Blog.objects.filter(title='My Blog').explain(verbose=True, analyze=True))\nSeq Scan on public.blog (cost=0.00..35.50 rows=10 width=12) (actual time=0.004..0.004 rows=10 loops=1)\n Output: id, title\n Filter: (blog.title = 'My Blog'::bpchar)\nPlanning time: 0.064 ms\nExecution time: 0.058 ms\nOn some databases, flags may cause the query to be executed which could have\nadverse effects on your database. For example, the ANALYZE flag supported\nby MariaDB, MySQL 8.0.18+, and PostgreSQL could result in changes to data if\nthere are triggers or if a function is called, even for a SELECT query.
FieldLink 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().
Untuk sebuah perkenalan, lihat models and database queries documentation 1.
\nPencarian siap-pakai Dajngo didaftarkan dibawah. Itu juga memungkinkan menulis custom lookups untuk bidang-bidang model.
\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#Pencocokan tepat. Jika nilai disediakan untuk perbandingan adalah None, itu akan diartikan sebagai sebuah SQL NULL (lihat isnull untuk rincian lebih).
Contoh:
\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;\nCatat permintaan pertama akan cocok 'Beatles Blog', 'beatles blog', 'BeAtLes BLoG', dll.
containsLink to this heading#Case-sensitive containment test.
\nContoh:
\nEntry.objects.get(headline__contains='Lennon')\nSetara SQL:
\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')\nSetara SQL:
\nSELECT ... WHERE headline ILIKE '%Lennon%';\ninLink to this heading#In a given iterable; often a list, tuple, or queryset. It's not a common use\ncase, but strings (being iterables) are accepted.
\nContoh:
\nEntry.objects.filter(id__in=[1, 3, 4])\nEntry.objects.filter(headline__in='abc')\nSQL equivalents:
\nSELECT ... WHERE id IN (1, 3, 4);\nSELECT ... WHERE headline IN ('a', 'b', 'c');\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)\nContoh ini akan memunculkan sebuah pengecualian, sejak permintaan paling dalam mencoba mengeluarkan nilai dua bidang, dimana hanya satu yang diharapkan:
\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)\nSetara SQL:
\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#Dimulai-dengan kasus-peka.
\nContoh:
\nEntry.objects.filter(headline__startswith='Lennon')\nSetara SQL:
\nSELECT ... WHERE headline LIKE 'Lennon%';\nSQLite tidak mendukung kasus-peka pernyataan LIKE; startswith bertindak seperti istartswith untuk SQLite.
istartswithLink to this heading#Dimulai-dengan kasus-tidak-peka.
\nContoh:
\nEntry.objects.filter(headline__istartswith='Lennon')\nSetara SQL:
\nSELECT ... WHERE headline ILIKE 'Lennon%';\nendswithLink to this heading#Diakhiri-dengan kasus-peka.
\nContoh:
\nEntry.objects.filter(headline__endswith='Lennon')\nSetara SQL:
\nSELECT ... WHERE headline LIKE '%Lennon';\niendswithLink to this heading#Diakhiri-dengan kasus-tidak-peka.
\nContoh:
\nEntry.objects.filter(headline__iendswith='Lennon')\nSetara SQL:
\nSELECT ... WHERE headline ILIKE '%Lennon'\nrangeLink to this heading#Jangkauan percobaan (termasuk).
\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))\nSetara SQL:
\nSELECT ... WHERE pub_date BETWEEN '2005-01-01' and '2005-03-31';\nAnda dapat menggunakan range dimanapun anda dapat gunakan BETWEEN dalam SQL -- untuk tanggal, angka bahkan karakter.
dateLink to this heading#Untuk bidang datetime, melemparkan nilai sebagai tanggal. Mengizinkan mengikat pencarian bidang tambahan. Mengambil nilai data.
\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. This requires time zone definitions in the\ndatabase.
yearLink to this heading#Untuk bidang tanggal dan datetime, sebuah kecocokan tanggal tepat. Mengizinkan mengikat tambahan bidang pencarian. Mengambil sebuah tahun integer.
\nContoh:
\nEntry.objects.filter(pub_date__year=2005)\nEntry.objects.filter(pub_date__year__gte=2005)\nSetara SQL:
\nSELECT ... WHERE pub_date BETWEEN '2005-01-01' AND '2005-12-31';\nSELECT ... WHERE pub_date >= '2005-01-01';\n(Sintaksis SQL tepat beragam untuk setiap mesin basisdata.)
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
iso_yearLink to this heading#For date and datetime fields, an exact ISO 8601 week-numbering year match.\nAllows chaining additional field lookups. Takes an integer year.
\nContoh:
\nEntry.objects.filter(pub_date__iso_year=2005)\nEntry.objects.filter(pub_date__iso_year__gte=2005)\n(Sintaksis SQL tepat beragam untuk setiap mesin basisdata.)
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
monthLink to this heading#Untuk bidang tanggal dan datetime, sebuah kecocokan bulan yang tepat. Mengizinkan mengikat bidang pencarian tambahan. Mengambil sebuah integer 1 (Januari) sampai 12 (Desember).
\nContoh:
\nEntry.objects.filter(pub_date__month=12)\nEntry.objects.filter(pub_date__month__gte=6)\nSetara SQL:
\nSELECT ... WHERE EXTRACT('month' FROM pub_date) = '12';\nSELECT ... WHERE EXTRACT('month' FROM pub_date) >= '6';\n(Sintaksis SQL tepat beragam untuk setiap mesin basisdata.)
\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)\nSetara SQL:
\nSELECT ... WHERE EXTRACT('day' FROM pub_date) = '3';\nSELECT ... WHERE EXTRACT('day' FROM pub_date) >= '3';\n(Sintaksis SQL tepat beragam untuk setiap mesin basisdata.)
\nCatat ini akan cocok dengan rekaman apapun dengan pub_date pada ahri ketiga dari bulan, seperti 3 Januari, 3 Juli, dll.
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
weekLink to this heading#For date and datetime fields, return the week number (1-52 or 53) according\nto ISO-8601, i.e., weeks start\non a Monday and the first week contains the year's first Thursday.
\nContoh:
\nEntry.objects.filter(pub_date__week=52)\nEntry.objects.filter(pub_date__week__gte=32, pub_date__week__lte=38)\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, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
week_dayLink to this heading#Untuk bidang tanggal dan datetime, pencocokan 'hari dari minggu'. Mengizinkan mengikat bidang pencarian tambahan.
\nMengambil nilai integer mewkili hari dari minggu dari 1 (Minggu) sampai 7 (Sabtu).
\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.
iso_week_dayLink to this heading#For date and datetime fields, an exact ISO 8601 day of the week match. Allows\nchaining additional field lookups.
\nTakes an integer value representing the day of the week from 1 (Monday) to 7\n(Sunday).
\nContoh:
\nEntry.objects.filter(pub_date__iso_week_day=1)\nEntry.objects.filter(pub_date__iso_week_day__gte=1)\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\n1 of the week), regardless of the month or year in which it occurs. Week days\nare indexed with day 1 being Monday and day 7 being Sunday.
When USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
quarterLink to this heading#For date and datetime fields, a 'quarter of the year' match. Allows chaining\nadditional field lookups. Takes an integer value between 1 and 4 representing\nthe quarter of the year.
\nContoh mengambil masukan dalam perempat kedua (1 April sampai 30 Juni):
\nEntry.objects.filter(pub_date__quarter=2)\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, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
timeLink to this heading#Untuk bidang datetime, melemparkan nilai sebagai waktu. Mengizinkan pencarian bidang tambahan. Mengambil nilai datetime.time.
Contoh:
\nEntry.objects.filter(pub_date__time=datetime.time(14, 30))\nEntry.objects.filter(pub_date__time__range=(datetime.time(8), datetime.time(17)))\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. This requires time zone definitions in the\ndatabase.
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)\nSetara SQL:
\nSELECT ... WHERE EXTRACT('hour' FROM timestamp) = '23';\nSELECT ... WHERE EXTRACT('hour' FROM time) = '5';\nSELECT ... WHERE EXTRACT('hour' FROM timestamp) >= '12';\n(Sintaksis SQL tepat beragam untuk setiap mesin basisdata.)
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
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)\nSetara SQL:
\nSELECT ... WHERE EXTRACT('minute' FROM timestamp) = '29';\nSELECT ... WHERE EXTRACT('minute' FROM time) = '46';\nSELECT ... WHERE EXTRACT('minute' FROM timestamp) >= '29';\n(Sintaksis SQL tepat beragam untuk setiap mesin basisdata.)
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
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)\nSetara SQL:
\nSELECT ... WHERE EXTRACT('second' FROM timestamp) = '31';\nSELECT ... WHERE EXTRACT('second' FROM time) = '2';\nSELECT ... WHERE EXTRACT('second' FROM timestamp) >= '31';\n(Sintaksis SQL tepat beragam untuk setiap mesin basisdata.)
\nWhen USE_TZ is True, datetime fields are converted to the\ncurrent time zone before filtering. This requires time zone definitions\nin the database.
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)\nSetara SQL:
\nSELECT ... WHERE pub_date IS NULL;\nregexLink to this heading#Pencocokan regular expression kasus-peka.
\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\nMenggunakan string mentah (misalnya, r'foo' daripada 'foo') untuk melewatkan sintaksis regular expression adalah dianjurkan.
iregexLink to this heading#Pencocokan regular expression kasus-tidak-peka.
\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.
Semua pengumpulan mempunyai parameter berikut secara umum:
\nexpressionsLink to this heading#Strings that reference fields on the model, transforms of the field, or\nquery expressions.
\n\noutput_fieldLink to this heading#Sebuah argumen pilihan yang mewakili model field 1 dari nilai balikan
\n\nfilterLink to this heading#Sebuah pilihan Q object yang digunakan untuk menyaring baris yang dikumpulkan.
Lihat Pengumpulan bersyarat and Penyaringan pada keterangan untuk contoh penggunaan.
\n**extraLink to this heading#Argumen kata kunci yang dapat menyediakan isi tambahan untuk SQL dibangkitkan dengan pengumpulan.
\nAvgLink to this heading#Mengembalikan arti nilai dari pernyataan yang diberikan, yang harus berupa numerik meskipun anda menentukan sebuah output_field berbeda.
Nama lain awalan: 1__avg
Return type: float if input is int, otherwise same as input\nfield, or output_field if supplied
Mempunyai satu argumen pilihan:
\nIf distinct=True, Avg returns the mean value of unique values.\nThis is the SQL equivalent of AVG(DISTINCT <field>). The default\nvalue is False.
CountLink to this heading#Mengembalikan sejumlah obyek yang terkait melalui pernyataan yang disediakan.
\nNama lain awalan: 1__count
Jenis kembalian: int
Mempunyai satu argumen pilihan:
\nJia distinct=True, hitungan hanya akan menyertakan contoh-contoh unik. Ini adalah setara SQL dari COUNT(DISTINCT <field>). Nilai awalan adalah False.
MaxLink to this heading#Mengembalikan nilai maksimal dari pernyataan yang diberikan.
\nNama lain awalan: 1__max
Jenis balikan: sama seperti bidang masukan, atau output_field jika didukung
MinLink to this heading#Mengembalikan nilai minimal dari pernyataan yang diberikan.
\nNama lain awalan: 1__min
Jenis balikan: sama seperti bidang masukan, atau output_field jika didukung
StdDevLink to this heading#Mengembalikan selisih standar dari data dalam pernyataan yang disediakan.
\nNama lain awalan: 1__stddev
Return type: float if input is int, otherwise same as input\nfield, or output_field if supplied
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#Menghitung jumlah dari semua nilai dari pernyataan yang diberikan.
\nNama lain awalan: 1__sum
Jenis balikan: sama seperti bidang masukan, atau output_field jika didukung
Mempunyai satu argumen pilihan:
\nIf distinct=True, Sum returns the sum of unique values. This is\nthe SQL equivalent of SUM(DISTINCT <field>). The default value is\nFalse.
VarianceLink to this heading#Mengembalikan beragam dari data di pernyataan yang disediakan.
\nNama lain awalan: 1__variance
Return type: float if input is int, otherwise same as input\nfield, or output_field if supplied
Mempunyai satu argumen pilihan:
\nBy default, Variance returns the population variance. However,\nif sample=True, the return value will be the sample variance.