Semua dari bidang ini tersedia dari modul django.contrib.postgres.fields.
ArrayFieldLink to this heading#Sebuah bidang untuk menyimpan daftar data. Kebanyakan jenis bidang dapat digunakan, anda cukup melewatkan instance bidang lain sebagai base_field. Anda mungkin juga menentukan sebuah size. ArrayField dapat disarangkan untuk menyimpan larik dimensi-banyak.
If you give the field a default, ensure\nit's a callable such as list (for an empty default) or a callable that\nreturns a list (such as a function). Incorrectly using default=[]\ncreates a mutable default that is shared between all instances of\nArrayField.
Ini adalah sebuah argumen diwajibkan.
\nSpecifies the underlying data type and behavior for the array. It\nshould be an instance of a subclass of\nField. For example, it could be an\nIntegerField or a\nCharField. Most field types are permitted,\nwith the exception of those handling relational data\n(ForeignKey,\nOneToOneField and\nManyToManyField).
Itu memungkinkan menyarang bidang-bidang larik - anda dapat menentukan sebuah instance dari ArrayField sebagai base_field. Sebagai contoh:
from django.db import models\nfrom django.contrib.postgres.fields import ArrayField\n\nclass ChessBoard(models.Model):\n board = ArrayField(\n ArrayField(\n models.CharField(max_length=10, blank=True),\n size=8,\n ),\n size=8,\n )\nTransformation of values between the database and the model, validation\nof data and configuration, and serialization are all delegated to the\nunderlying base field.
\nIni adalah sebuah argumen pilihan.
\nIf passed, the array will have a maximum size as specified. This will\nbe passed to the database, although PostgreSQL at present does not\nenforce the restriction.
\nArrayFieldLink to this heading#There are a number of custom lookups and transforms for ArrayField.\nWe will use the following example model:
from django.db import models\nfrom django.contrib.postgres.fields import ArrayField\n\nclass Post(models.Model):\n name = models.CharField(max_length=200)\n tags = ArrayField(models.CharField(max_length=200), blank=True)\n\n def __str__(self): # __unicode__ on Python 2\n return self.name\ncontainsLink to this heading#The contains lookup is overridden on ArrayField. The\nreturned objects will be those where the values passed are a subset of the\ndata. It uses the SQL operator @>. For example:
>>> Post.objects.create(name='First post', tags=['thoughts', 'django'])\n>>> Post.objects.create(name='Second post', tags=['thoughts'])\n>>> Post.objects.create(name='Third post', tags=['tutorial', 'django'])\n\n>>> Post.objects.filter(tags__contains=['thoughts'])\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__contains=['django'])\n<QuerySet [<Post: First post>, <Post: Third post>]>\n\n>>> Post.objects.filter(tags__contains=['django', 'thoughts'])\n<QuerySet [<Post: First post>]>\ncontained_byLink to this heading#This is the inverse of the contains lookup -\nthe objects returned will be those where the data is a subset of the values\npassed. It uses the SQL operator <@. For example:
>>> Post.objects.create(name='First post', tags=['thoughts', 'django'])\n>>> Post.objects.create(name='Second post', tags=['thoughts'])\n>>> Post.objects.create(name='Third post', tags=['tutorial', 'django'])\n\n>>> Post.objects.filter(tags__contained_by=['thoughts', 'django'])\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__contained_by=['thoughts', 'django', 'tutorial'])\n<QuerySet [<Post: First post>, <Post: Second post>, <Post: Third post>]>\noverlapLink to this heading#Returns objects where the data shares any results with the values passed. Uses\nthe SQL operator &&. For example:
>>> Post.objects.create(name='First post', tags=['thoughts', 'django'])\n>>> Post.objects.create(name='Second post', tags=['thoughts'])\n>>> Post.objects.create(name='Third post', tags=['tutorial', 'django'])\n\n>>> Post.objects.filter(tags__overlap=['thoughts'])\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__overlap=['thoughts', 'tutorial'])\n<QuerySet [<Post: First post>, <Post: Second post>, <Post: Third post>]>\nlenLink to this heading#Returns the length of the array. The lookups available afterwards are those\navailable for IntegerField. For example:
>>> Post.objects.create(name='First post', tags=['thoughts', 'django'])\n>>> Post.objects.create(name='Second post', tags=['thoughts'])\n\n>>> Post.objects.filter(tags__len=1)\n<QuerySet [<Post: Second post>]>\nThis class of transforms allows you to index into the array in queries. Any\nnon-negative integer can be used. There are no errors if it exceeds the\nsize of the array. The lookups available after the\ntransform are those from the base_field. For\nexample:
>>> Post.objects.create(name='First post', tags=['thoughts', 'django'])\n>>> Post.objects.create(name='Second post', tags=['thoughts'])\n\n>>> Post.objects.filter(tags__0='thoughts')\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__1__iexact='Django')\n<QuerySet [<Post: First post>]>\n\n>>> Post.objects.filter(tags__276='javascript')\n<QuerySet []>\nThis class of transforms allow you to take a slice of the array. Any two\nnon-negative integers can be used, separated by a single underscore. The\nlookups available after the transform do not change. For example:
\n>>> Post.objects.create(name='First post', tags=['thoughts', 'django'])\n>>> Post.objects.create(name='Second post', tags=['thoughts'])\n>>> Post.objects.create(name='Third post', tags=['django', 'python', 'thoughts'])\n\n>>> Post.objects.filter(tags__0_1=['thoughts'])\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__0_2__contains=['thoughts'])\n<QuerySet [<Post: First post>, <Post: Second post>]>\nArrayFieldLink to this heading#At present using db_index will create a\nbtree index. This does not offer particularly significant help to querying.\nA more useful index is a GIN index, which you should create using a\nRunSQL operation.
CIText fieldsLink to this heading#A mixin to create case-insensitive text fields backed by the citext type.\nRead about the performance considerations prior to using it.
\nTo use citext, use the CITextExtension operation to\nsetup the citext extension in\nPostgreSQL before the first CreateModel migration operation.
Several fields that use the mixin are provided:
\nThese fields subclass CharField,\nEmailField, and\nTextField, respectively.
max_length won't be enforced in the database since citext behaves\nsimilar to PostgreSQL's text type.
HStoreFieldLink to this heading#A field for storing key-value pairs. The Python data type used is a\ndict. Keys must be strings, and values may be either strings or nulls\n(None in Python).
Untuk menggunakan bidang ini, anda akan butuh untuk:
\nTambah 'django.contrib.postgres' dalam INSTALLED_APPS anda.
Setup the hstore extension di PostgreSQL.
Anda akan melihat sebuah kesalahan seperti can't adapt type 'dict' jika anda melewati langkah pertama, atau type "hstore" does not exist jika anda melewati kedua.
HStoreFieldLink to this heading#In addition to the ability to query by key, there are a number of custom\nlookups available for HStoreField.
Kami akan menggunakan model contoh berikut:
\nfrom django.contrib.postgres.fields import HStoreField\nfrom django.db import models\n\nclass Dog(models.Model):\n name = models.CharField(max_length=200)\n data = HStoreField()\n\n def __str__(self): # __unicode__ on Python 2\n return self.name\nTo query based on a given key, you simply use that key as the lookup name:
\n>>> Dog.objects.create(name='Rufus', data={'breed': 'labrador'})\n>>> Dog.objects.create(name='Meg', data={'breed': 'collie'})\n\n>>> Dog.objects.filter(data__breed='collie')\n<QuerySet [<Dog: Meg>]>\nYou can chain other lookups after key lookups:
\n>>> Dog.objects.filter(data__breed__contains='l')\n<QuerySet [<Dog: Rufus>, <Dog: Meg>]>\nIf the key you wish to query by clashes with the name of another lookup, you\nneed to use the hstorefield.contains lookup instead.
containsLink to this heading#The contains lookup is overridden on\nHStoreField. The returned objects are\nthose where the given dict of key-value pairs are all contained in the\nfield. It uses the SQL operator @>. For example:
>>> Dog.objects.create(name='Rufus', data={'breed': 'labrador', 'owner': 'Bob'})\n>>> Dog.objects.create(name='Meg', data={'breed': 'collie', 'owner': 'Bob'})\n>>> Dog.objects.create(name='Fred', data={})\n\n>>> Dog.objects.filter(data__contains={'owner': 'Bob'})\n<QuerySet [<Dog: Rufus>, <Dog: Meg>]>\n\n>>> Dog.objects.filter(data__contains={'breed': 'collie'})\n<QuerySet [<Dog: Meg>]>\ncontained_byLink to this heading#This is the inverse of the contains lookup -\nthe objects returned will be those where the key-value pairs on the object are\na subset of those in the value passed. It uses the SQL operator <@. For\nexample:
>>> Dog.objects.create(name='Rufus', data={'breed': 'labrador', 'owner': 'Bob'})\n>>> Dog.objects.create(name='Meg', data={'breed': 'collie', 'owner': 'Bob'})\n>>> Dog.objects.create(name='Fred', data={})\n\n>>> Dog.objects.filter(data__contained_by={'breed': 'collie', 'owner': 'Bob'})\n<QuerySet [<Dog: Meg>, <Dog: Fred>]>\n\n>>> Dog.objects.filter(data__contained_by={'breed': 'collie'})\n<QuerySet [<Dog: Fred>]>\nhas_keyLink to this heading#Returns objects where the given key is in the data. Uses the SQL operator\n?. For example:
>>> Dog.objects.create(name='Rufus', data={'breed': 'labrador'})\n>>> Dog.objects.create(name='Meg', data={'breed': 'collie', 'owner': 'Bob'})\n\n>>> Dog.objects.filter(data__has_key='owner')\n<QuerySet [<Dog: Meg>]>\nhas_any_keysLink to this heading#Returns objects where any of the given keys are in the data. Uses the SQL\noperator ?|. For example:
>>> Dog.objects.create(name='Rufus', data={'breed': 'labrador'})\n>>> Dog.objects.create(name='Meg', data={'owner': 'Bob'})\n>>> Dog.objects.create(name='Fred', data={})\n\n>>> Dog.objects.filter(data__has_any_keys=['owner', 'breed'])\n<QuerySet [<Dog: Rufus>, <Dog: Meg>]>\nhas_keysLink to this heading#Returns objects where all of the given keys are in the data. Uses the SQL operator\n?&. For example:
>>> Dog.objects.create(name='Rufus', data={})\n>>> Dog.objects.create(name='Meg', data={'breed': 'collie', 'owner': 'Bob'})\n\n>>> Dog.objects.filter(data__has_keys=['breed', 'owner'])\n<QuerySet [<Dog: Meg>]>\nkeysLink to this heading#Returns objects where the array of keys is the given value. Note that the order\nis not guaranteed to be reliable, so this transform is mainly useful for using\nin conjunction with lookups on\nArrayField. Uses the SQL function\nakeys(). For example:
>>> Dog.objects.create(name='Rufus', data={'toy': 'bone'})\n>>> Dog.objects.create(name='Meg', data={'breed': 'collie', 'owner': 'Bob'})\n\n>>> Dog.objects.filter(data__keys__overlap=['breed', 'toy'])\n<QuerySet [<Dog: Rufus>, <Dog: Meg>]>\nvaluesLink to this heading#Returns objects where the array of values is the given value. Note that the\norder is not guaranteed to be reliable, so this transform is mainly useful for\nusing in conjunction with lookups on\nArrayField. Uses the SQL function\navalues(). For example:
>>> Dog.objects.create(name='Rufus', data={'breed': 'labrador'})\n>>> Dog.objects.create(name='Meg', data={'breed': 'collie', 'owner': 'Bob'})\n\n>>> Dog.objects.filter(data__values__contains=['collie'])\n<QuerySet [<Dog: Meg>]>\nJSONFieldLink to this heading#A field for storing JSON encoded data. In Python the data is represented in\nits Python native format: dictionaries, lists, strings, numbers, booleans\nand None.
An optional JSON-encoding class to serialize data types not supported\nby the standard JSON serializer (datetime, uuid, etc.). For\nexample, you can use the\nDjangoJSONEncoder class or any\nother json.JSONEncoder subclass.
When the value is retrieved from the database, it will be in the format\nchosen by the custom encoder (most often a string), so you'll need to\ntake extra steps to convert the value back to the initial data type\n(Model.from_db() and\nField.from_db_value()\nare two possible hooks for that purpose). Your deserialization may need\nto account for the fact that you can't be certain of the input type.\nFor example, you run the risk of returning a datetime that was\nactually a string that just happened to be in the same format chosen\nfor datetimes.
If you give the field a default, ensure\nit's a callable such as dict (for an empty default) or a callable that\nreturns a dict (such as a function). Incorrectly using default={}\ncreates a mutable default that is shared between all instances of\nJSONField.
JSONFieldLink to this heading#Kami akan menggunakan model contoh berikut:
\nfrom django.contrib.postgres.fields import JSONField\nfrom django.db import models\n\nclass Dog(models.Model):\n name = models.CharField(max_length=200)\n data = JSONField()\n\n def __str__(self): # __unicode__ on Python 2\n return self.name\nUntuk meminta berdasarkan kunci kamus yang diberikan, cukup gunakan kunci itu sebagai nama pencarian:
\n>>> Dog.objects.create(name='Rufus', data={\n... 'breed': 'labrador',\n... 'owner': {\n... 'name': 'Bob',\n... 'other_pets': [{\n... 'name': 'Fishy',\n... }],\n... },\n... })\n>>> Dog.objects.create(name='Meg', data={'breed': 'collie'})\n\n>>> Dog.objects.filter(data__breed='collie')\n<QuerySet [<Dog: Meg>]>\nMultiple keys can be chained together to form a path lookup:
\n>>> Dog.objects.filter(data__owner__name='Bob')\n<QuerySet [<Dog: Rufus>]>\nJika kunci adalah sebuah integer, itu akan ditafsirkan sebagai sebuah pencarian indeks dalam sebuah larik:
\n>>> Dog.objects.filter(data__owner__other_pets__0__name='Fishy')\n<QuerySet [<Dog: Rufus>]>\nIf the key you wish to query by clashes with the name of another lookup, use\nthe jsonfield.contains lookup instead.
If only one key or index is used, the SQL operator -> is used. If multiple\noperators are used then the #> operator is used.
JSONField berbagi pencarian terkait pada penahanan dan kunci dengan HStoreField.
contains (menerima JSON apapun daripada hanya sebuah kamus dari string)
contained_by (menerima JSON apapun daripada hanya sebuah kamus dari string)
:lookup
There are five range field types, corresponding to the built-in range types in\nPostgreSQL. These fields are used to store a range of values; for example the\nstart and end timestamps of an event, or the range of ages an activity is\nsuitable for.
\nAll of the range fields translate to psycopg2 Range objects in python, but also accept tuples as input if no bounds\ninformation is necessary. The default is lower bound included, upper bound\nexcluded; that is, [).
IntegerRangeFieldLink to this heading#Stores a range of integers. Based on an\nIntegerField. Represented by an int4range in\nthe database and a NumericRange in\nPython.
Regardless of the bounds specified when saving the data, PostgreSQL always\nreturns a range in a canonical form that includes the lower bound and\nexcludes the upper bound; that is [).
BigIntegerRangeFieldLink to this heading#Stores a range of large integers. Based on a\nBigIntegerField. Represented by an int8range\nin the database and a NumericRange in\nPython.
Regardless of the bounds specified when saving the data, PostgreSQL always\nreturns a range in a canonical form that includes the lower bound and\nexcludes the upper bound; that is [).
FloatRangeFieldLink to this heading#Stores a range of floating point values. Based on a\nFloatField. Represented by a numrange in the\ndatabase and a NumericRange in Python.
DateTimeRangeFieldLink to this heading#Stores a range of timestamps. Based on a\nDateTimeField. Represented by a tstzrange in\nthe database and a DateTimeTZRange in\nPython.
DateRangeFieldLink to this heading#Stores a range of dates. Based on a\nDateField. Represented by a daterange in the\ndatabase and a DateRange in Python.
Regardless of the bounds specified when saving the data, PostgreSQL always\nreturns a range in a canonical form that includes the lower bound and\nexcludes the upper bound; that is [).
There are a number of custom lookups and transforms for range fields. They are\navailable on all the above fields, but we will use the following example\nmodel:
\nfrom django.contrib.postgres.fields import IntegerRangeField\nfrom django.db import models\n\nclass Event(models.Model):\n name = models.CharField(max_length=200)\n ages = IntegerRangeField()\n start = models.DateTimeField()\n\n def __str__(self): # __unicode__ on Python 2\n return self.name\nWe will also use the following example objects:
\n>>> import datetime\n>>> from django.utils import timezone\n>>> now = timezone.now()\n>>> Event.objects.create(name='Soft play', ages=(0, 10), start=now)\n>>> Event.objects.create(name='Pub trip', ages=(21, None), start=now - datetime.timedelta(days=1))\nand NumericRange:
>>> from psycopg2.extras import NumericRange\nAs with other PostgreSQL fields, there are three standard containment\noperators: contains, contained_by and overlap, using the SQL\noperators @>, <@, and && respectively.
containsLink to this heading#>>> Event.objects.filter(ages__contains=NumericRange(4, 5))\n<QuerySet [<Event: Soft play>]>\ncontained_byLink to this heading#>>> Event.objects.filter(ages__contained_by=NumericRange(0, 15))\n<QuerySet [<Event: Soft play>]>\nThe contained_by lookup is also available on the non-range field types:\nIntegerField,\nBigIntegerField,\nFloatField, DateField,\nand DateTimeField. For example:
>>> from psycopg2.extras import DateTimeTZRange\n>>> Event.objects.filter(start__contained_by=DateTimeTZRange(\n... timezone.now() - datetime.timedelta(hours=1),\n... timezone.now() + datetime.timedelta(hours=1),\n... )\n<QuerySet [<Event: Soft play>]>\noverlapLink to this heading#>>> Event.objects.filter(ages__overlap=NumericRange(8, 12))\n<QuerySet [<Event: Soft play>]>\nRange fields support the standard lookups: lt, gt,\nlte and gte. These are not particularly helpful - they\ncompare the lower bounds first and then the upper bounds only if necessary.\nThis is also the strategy used to order by a range field. It is better to use\nthe specific range comparison operators.
fully_ltLink to this heading#The returned ranges are strictly less than the passed range. In other words,\nall the points in the returned range are less than all those in the passed\nrange.
\n>>> Event.objects.filter(ages__fully_lt=NumericRange(11, 15))\n<QuerySet [<Event: Soft play>]>\nfully_gtLink to this heading#The returned ranges are strictly greater than the passed range. In other words,\nthe all the points in the returned range are greater than all those in the\npassed range.
\n>>> Event.objects.filter(ages__fully_gt=NumericRange(11, 15))\n<QuerySet [<Event: Pub trip>]>\nnot_ltLink to this heading#The returned ranges do not contain any points less than the passed range, that\nis the lower bound of the returned range is at least the lower bound of the\npassed range.
\n>>> Event.objects.filter(ages__not_lt=NumericRange(0, 15))\n<QuerySet [<Event: Soft play>, <Event: Pub trip>]>\nnot_gtLink to this heading#The returned ranges do not contain any points greater than the passed range, that\nis the upper bound of the returned range is at most the upper bound of the\npassed range.
\n>>> Event.objects.filter(ages__not_gt=NumericRange(3, 10))\n<QuerySet [<Event: Soft play>]>\nadjacent_toLink to this heading#The returned ranges share a bound with the passed range.
\n>>> Event.objects.filter(ages__adjacent_to=NumericRange(10, 21))\n<QuerySet [<Event: Soft play>, <Event: Pub trip>]>\nThere are three transforms available for use in queries. You can extract the\nlower or upper bound, or query based on emptiness.
\nstartswithLink to this heading#Returned objects have the given lower bound. Can be chained to valid lookups\nfor the base field.
\n>>> Event.objects.filter(ages__startswith=21)\n<QuerySet [<Event: Pub trip>]>\nendswithLink to this heading#Returned objects have the given upper bound. Can be chained to valid lookups\nfor the base field.
\n>>> Event.objects.filter(ages__endswith=10)\n<QuerySet [<Event: Soft play>]>\nisemptyLink to this heading#Returned objects are empty ranges. Can be chained to valid lookups for a\nBooleanField.
>>> Event.objects.filter(ages__isempty=True)\n<QuerySet []>\nPostgreSQL allows the definition of custom range types. Django's model and form\nfield implementations use base classes below, and psycopg2 provides a\nregister_range() to allow use of custom range\ntypes.
Base class for model range fields.
\nThe model field class to use.
\nThe psycopg2 range type to use.
\nThe form field class to use. Should be a subclass of\ndjango.contrib.postgres.forms.BaseRangeField.
Base class for form range fields.
\nThe form field to use.
\nThe psycopg2 range type to use.
\n