This document describes the details of the Model 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.
\nTo create a new instance of a model, just instantiate it like any other Python\nclass:
\nThe keyword arguments are simply the names of the fields you've defined on your\nmodel. Note that instantiating a model in no way touches your database; for\nthat, you need to save().
The from_db() method can be used to customize model instance creation\nwhen loading from the database.
The db argument contains the database alias for the database the model\nis loaded from, field_names contains the names of all loaded fields, and\nvalues contains the loaded values for each field in field_names. The\nfield_names are in the same order as the values. If all of the model's\nfields are present, then values are guaranteed to be in the order\n__init__() expects them. That is, the instance can be created by\ncls(*values). If any fields are deferred, they won't appear in\nfield_names. In that case, assign a value of django.db.models.DEFERRED\nto each of the missing fields.
In addition to creating the new model, the from_db() method must set the\nadding and db flags in the new instance's _state attribute.
Below is an example showing how to record the initial values of fields that\nare loaded from the database:
\nfrom django.db.models import DEFERRED\n\n@classmethod\ndef from_db(cls, db, field_names, values):\n # Default implementation of from_db() (subject to change and could\n # be replaced with super()).\n if len(values) != len(cls._meta.concrete_fields):\n values = list(values)\n values.reverse()\n values = [\n values.pop() if f.attname in field_names else DEFERRED\n for f in cls._meta.concrete_fields\n ]\n instance = cls(*values)\n instance._state.adding = False\n instance._state.db = db\n # customization to store the original field values on the instance\n instance._loaded_values = dict(zip(field_names, values))\n return instance\n\ndef save(self, *args, **kwargs):\n # Check how the current values differ from ._loaded_values. For example,\n # prevent changing the creator_id of the model. (This example doesn't\n # support cases where 'creator_id' is deferred).\n if not self._state.adding and (\n self.creator_id != self._loaded_values['creator_id']):\n raise ValueError("Updating the value of creator isn't allowed")\n super().save(*args, **kwargs)\nThe example above shows a full from_db() implementation to clarify how that\nis done. In this case it would of course be possible to just use super() call\nin the from_db() method.
Jika anda menghapus sebuah bidang dari sebuah contoh model, mengakses itu kembali memuat kembali nilai dari basisdata:
\n>>> obj = MyModel.objects.first()\n>>> del obj.field\n>>> obj.field # Loads the field from the database\nIf you need to reload a model's values from the database, you can use the\nrefresh_from_db() method. When this method is called without arguments the\nfollowing is done:
All non-deferred fields of the model are updated to the values currently\npresent in the database.
Any cached relations are cleared from the reloaded instance.
Hanya bidang-bidang dari model dimuat kembali dari basisdata. Nilai-nilai bergantung-basisdata lain seperti keterangan tidak dimuat kembali. Atribut @cached_property apapun tidak dibersihkan juga.
The reloading happens from the database the instance was loaded from, or from\nthe default database if the instance wasn't loaded from the database. The\nusing argument can be used to force the database used for reloading.
Itu memungkinkan untuk memaksa kumpulan dari bidang-bidang dimuat menggunakan argumen field.
Sebagai contoh, untuk mencoba bahwa sebuah panggilan update() dihasilkan dalam pembaharuan diharapkan, anda dapat menulis sebuah percobaan miriip seperti ini:
def test_update_result(self):\n obj = MyModel.objects.create(val=1)\n MyModel.objects.filter(pk=obj.pk).update(val=F('val') + 1)\n # At this point obj.val is still 1, but the value in the database\n # was updated to 2. The object's updated value needs to be reloaded\n # from the database.\n obj.refresh_from_db()\n self.assertEqual(obj.val, 2)\nCatat bahwa ketika bidang ditangguhkan diakses, memuat nilai bidang tertangguh terjadi melalui metode ini. dengan demikian itu adalah mungkin untuk menyesuaian cara penangguhan memuat terjadi. Contoh dibawah menunjukkan bagaimana satu dapat dimuat kembali dari bidang-bidang instance ketika bidang tertangguhkan dimuat:
\nclass ExampleModel(models.Model):\n def refresh_from_db(self, using=None, fields=None, **kwargs):\n # fields contains the name of the deferred field to be\n # loaded.\n if fields is not None:\n fields = set(fields)\n deferred_fields = self.get_deferred_fields()\n # If any deferred field is going to be loaded\n if fields.intersection(deferred_fields):\n # then load all of them\n fields = fields.union(deferred_fields)\n super().refresh_from_db(using, fields, **kwargs)\nA helper method that returns a set containing the attribute names of all those\nfields that are currently deferred for this model.
\nAda tidak langkah terlibat dalam mengesahkan sebuah model:
\nMensahkan bidang-bidang model - Model.clean_fields()
Mensahkan model sebagai sebuah keseluruhan - Model.clean_fields()
Mensahkan keunikan bidang - Model.validate_unique()
Semua tiga langkah dilakukan ketika anda memanggil metode full_clean() model.
Ketika anda menggunakan ModelForm, panggilan pada is_valid() akan melakukan langkah-langkah pengesahan ini untuk semua bidang yang disertakan pada formulir. Lihat ModelForm documentation ` untuk informasi lebih. Anda hanya butuh memanggil metode :meth:`~Model.full_clean() model jika anda berencana menangani kesalahan pengesahan anda sendiri, atau jika anda telah tidak menyertakan bidang-bidang dari ModelForm yang membutuhkan pengesahan.
Metode ini memanggil Model.clean_fields(), Model.clean(), dan Model.validate_unique() (jika validate_unique adalah True), dalam urutan itu dan memunculkan ValidationError yang mempunyai atribut message_dict mengandung kesalahan dari semua tiga tingkatan.
Argumen exclude pilihan dapat digunakan untuk menyediakan daftar dari nama-nama bidang yang dapat tidak disertakan dari pengesahan dan pembersihan. ModelForm menggunakan argumen ini untuk tidak menyertakan bidang-bidang yang tidak hadir pada formulir anda dari menjadi disahkan sejak kesalahan apapun muncul tidak dapat diperbaiki oleh pengguna.
Catata bahwa full_clean() tidak akan dipanggil otomatis ketika anda memanggil metode save() model anda. Anda akan butuh memanggil itu secara manual ketika anda ingin menjalankan pengesahan model satu-langkah untuk anda sendiri secara manual model dibuat. Sebagai contoh:
from django.core.exceptions import ValidationError\ntry:\n article.full_clean()\nexcept ValidationError as e:\n # Do something based on the errors contained in e.message_dict.\n # Display them to a user, or handle them programmatically.\n pass\nLangkah pertama full_clean() lakukan adalah membersihkan setiap bidang masing-masing.
Metode ini akan mensahkan semua bidang pada model anda. Pilihan argumen exclude membuat anda menyediakan daftar dari nama-nama bidang untuk tidak disertakan dari pengesahan. itu akan memunculkan ValidationError jika bidang apapun gagal mensahkan.
Langkah kedua full_clean() lakukan adalah memanggil Model.clean(). Metode ini harus ditimpa untuk melakukan penyesuaian keabsahan pada model anda.
Metode ini harus digunakan untuk menyediakan pengesahan model penyesuaian, dan untuk merubah atribut pada model anda jika diinginkan. Sebagai contoh, anda dapat menggunakan itu secara otomatis menyediakan nilai untuk bidang, atau melakukan pengesahan yang membutuhkan akses pada lebih dari bidang tunggal:
\nimport datetime\nfrom django.core.exceptions import ValidationError\nfrom django.db import models\nfrom django.utils.translation import gettext_lazy as _\n\nclass Article(models.Model):\n ...\n def clean(self):\n # Don't allow draft entries to have a pub_date.\n if self.status == 'draft' and self.pub_date is not None:\n raise ValidationError(_('Draft entries may not have a publication date.'))\n # Set the pub_date for published items if it hasn't been set already.\n if self.status == 'published' and self.pub_date is None:\n self.pub_date = datetime.date.today()\nCatat, bagaimanapun, itu seeprti Model.full_clean(), sebuah metode clean() model tidak dipanggil ketika anda memanggil metode save() model anda.
Dalam contoh diatas, pengecualian ValidationError dimunculkan oleh Model.clean() telah dipakai dengan string, sehingga itu akan tetap disimpan dalam kunci dictionary khusus, NON_FIELD_ERRORS. Kunci ini digunakan untuk kesalahan-kesalahan yang diikat pada keseluruhan model daripada bidang tertentu:
from django.core.exceptions import NON_FIELD_ERRORS, ValidationError\ntry:\n article.full_clean()\nexcept ValidationError as e:\n non_field_errors = e.message_dict[NON_FIELD_ERRORS]\nUntuk memberikan pengecualian pada bidang khusus, pemakaian ValidationError dengan sebuah dictionary, dimana kunci-kunci adalah nama-nama bidang. Kami dapat memperbaharui contoh sebelumnya untuk memberikan kesalahan pada bidang pub_date:
class Article(models.Model):\n ...\n def clean(self):\n # Don't allow draft entries to have a pub_date.\n if self.status == 'draft' and self.pub_date is not None:\n raise ValidationError({'pub_date': _('Draft entries may not have a publication date.')})\n ...\nJika anda mengetahui kesalahan dalam banyak bidang selama Model.clean(), anda dapat juga melewatkan nama-nama bidang pemetaan dictionary pada kesalahan:
raise ValidationError({\n 'title': ValidationError(_('Missing title.'), code='required'),\n 'pub_date': ValidationError(_('Invalid date.'), code='invalid'),\n})\nAkhirnya, full_clean() akan memeriksa batsan unik pada model.
Metode ini mirip pada clean_fields(), tetapi mensahkan semua batasan-batasan unik pada model anda daripada nilai bidang tersendiri. Argumen exclude pilihan mengizinkan anda menyediakan daftar dari nama-nama bidang untuk tidak menyertakan dari pengesahan. Itu akan memunculkan ValidationError jika bidang apapun gagal pengesahan.
Catat bahwa jika anda menyediakan sebuah argumen exclude pada validate_unique(), batasan unique_together apapun melibatkan satu dari bidang-bidang anda sediakan tidak akan diperiksa.
Untuk menyimpan sebuah obyek kembali ke basisdata, panggil save():
If you want customized saving behavior, you can override this save()\nmethod. See Menimpa metode model yang detetapkan for more details.
The model save process also has some subtleties; see the sections below.
\nJika sebuah model mempunyai AutoField — sebuah primary key menaik-otomatis - kemudian nilai menaik-otomatis akan dihitung dan disimpan sebagai sebuah atribut pada obyek anda pertama kali anda memanggil save():
>>> b2 = Blog(name='Cheddar Talk', tagline='Thoughts on cheese.')\n>>> b2.id # Returns None, because b doesn't have an ID yet.\n>>> b2.save()\n>>> b2.id # Returns the ID of your new object.\nThere's no way to tell what the value of an ID will be before you call\nsave(), because that value is calculated by your database, not by Django.
Untuk kenyamanan, setiap model memiliki sebuah AutoField bernama id secara awalan meskipun anda secara tegas menentukan primary_key=True pada bidang dalam model anda. Lihat dokumentasi untuk AutoField untuk rincian lebih.
pkLink to this heading#Meskipun apakah anda menentukan bidang primary key anda sendiri, atau membiarkan Django mendukung satu untuk anda, setiap model akan memiliki sifat dipanggil pk. Itu berperilaku seperti atribut biasa pada model, tetapi sebenarnya sebuah nama lain untuk atribut mana saja adalah bidang primary key untuk model. Anda dapat membaca dan mensetel nilai ini, sama seperti anda untuk atribut lain, dan itu akan memperbaharui bidang benar dalam model.
If a model has an AutoField but you want to define a\nnew object's ID explicitly when saving, just define it explicitly before\nsaving, rather than relying on the auto-assignment of the ID:
>>> b3 = Blog(id=3, name='Cheddar Talk', tagline='Thoughts on cheese.')\n>>> b3.id # Returns 3.\n>>> b3.save()\n>>> b3.id # Returns 3.\nIf you assign auto-primary-key values manually, make sure not to use an\nalready-existing primary-key value! If you create a new object with an explicit\nprimary-key value that already exists in the database, Django will assume you're\nchanging the existing record rather than creating a new one.
\nDiberikan contoh blog 'Cheddar Talk' diatas, contoh ini akan menimpa rekaman sebelumnya di basisdata:
b4 = Blog(id=3, name='Not Cheddar', tagline='Anything but cheese.')\nb4.save() # Overrides the previous blog with ID=3!\nLihat How Django knows to UPDATE vs. INSERT, dibawah, untuk alasan ini terjadi.
\nExplicitly specifying auto-primary-key values is mostly useful for bulk-saving\nobjects, when you're confident you won't have primary-key collision.
\nIf you're using PostgreSQL, the sequence associated with the primary key might\nneed to be updated; see Manual-menentukan nilai-nilai dari primary key peningkatan-otomatis.
\nKetika anda menyimpan sebuah obyek, Django melakukan langkah-langkah berikut:
\nEmit a pre-save signal. The pre_save\nsignal is sent, allowing any functions listening for that signal to do\nsomething.
Preprocess the data. Each field's\npre_save() method is called to perform any\nautomated data modification that's needed. For example, the date/time fields\noverride pre_save() to implement\nauto_now_add and\nauto_now.
Prepare the data for the database. Each field's\nget_db_prep_save() method is asked to provide\nits current value in a data type that can be written to the database.
Most fields don't require data preparation. Simple data types, such as\nintegers and strings, are 'ready to write' as a Python object. However, more\ncomplex data types often require some modification.
\nFor example, DateField fields use a Python\ndatetime object to store data. Databases don't store datetime\nobjects, so the field value must be converted into an ISO-compliant date\nstring for insertion into the database.
Insert the data into the database. The preprocessed, prepared data is\ncomposed into an SQL statement for insertion into the database.
Emit a post-save signal. The post_save\nsignal is sent, allowing any functions listening for that signal to do\nsomething.
You may have noticed Django database objects use the same save() method\nfor creating and changing objects. Django abstracts the need to use INSERT\nor UPDATE SQL statements. Specifically, when you call save(), Django\nfollows this algorithm:
If the object's primary key attribute is set to a value that evaluates to\nTrue (i.e., a value other than None or the empty string), Django\nexecutes an UPDATE.
If the object's primary key attribute is not set or if the UPDATE\ndidn't update anything, Django executes an INSERT.
The one gotcha here is that you should be careful not to specify a primary-key\nvalue explicitly when saving new objects, if you cannot guarantee the\nprimary-key value is unused. For more on this nuance, see Explicitly specifying\nauto-primary-key values above and Forcing an INSERT or UPDATE below.
\nIn Django 1.5 and earlier, Django did a SELECT when the primary key\nattribute was set. If the SELECT found a row, then Django did an UPDATE,\notherwise it did an INSERT. The old algorithm results in one more query in\nthe UPDATE case. There are some rare cases where the database doesn't\nreport that a row was updated even if the database contains a row for the\nobject's primary key value. An example is the PostgreSQL ON UPDATE trigger\nwhich returns NULL. In such cases it is possible to revert to the old\nalgorithm by setting the select_on_save\noption to True.
In some rare circumstances, it's necessary to be able to force the\nsave() method to perform an SQL INSERT and not fall back to\ndoing an UPDATE. Or vice-versa: update, if possible, but not insert a new\nrow. In these cases you can pass the force_insert=True or\nforce_update=True parameters to the save() method.\nObviously, passing both parameters is an error: you cannot both insert and\nupdate at the same time!
It should be very rare that you'll need to use these parameters. Django will\nalmost always do the right thing and trying to override that will lead to\nerrors that are difficult to track down. This feature is for advanced use\nonly.
\nMenggunakan update_fields akan memaksa sebuah perbaharuan mirip pada force_update.
Sometimes you'll need to perform a simple arithmetic task on a field, such\nas incrementing or decrementing the current value. The obvious way to\nachieve this is to do something like:
\n>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')\n>>> product.number_sold += 1\n>>> product.save()\nIf the old number_sold value retrieved from the database was 10, then\nthe value of 11 will be written back to the database.
The process can be made robust, avoiding a race condition, as well as slightly faster by expressing\nthe update relative to the original field value, rather than as an explicit\nassignment of a new value. Django provides F expressions for performing this kind of relative update. Using\nF expressions, the previous example is expressed\nas:
>>> from django.db.models import F\n>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')\n>>> product.number_sold = F('number_sold') + 1\n>>> product.save()\nFor more details, see the documentation on F expressions and their use in update queries.
If save() is passed a list of field names in keyword argument\nupdate_fields, only the fields named in that list will be updated.\nThis may be desirable if you want to update just one or a few fields on\nan object. There will be a slight performance benefit from preventing\nall of the model fields from being updated in the database. For example:
product.name = 'Name changed again'\nproduct.save(update_fields=['name'])\nThe update_fields argument can be any iterable containing strings. An\nempty update_fields iterable will skip the save. A value of None will\nperform an update on all fields.
Menentukan update_fields akan memaksa sebuah pembaharuan.
When saving a model fetched through deferred model loading\n(only() or\ndefer()) only the fields loaded\nfrom the DB will get updated. In effect there is an automatic\nupdate_fields in this case. If you assign or change any deferred field\nvalue, the field will be added to the updated fields.
Issues an SQL DELETE for the object. This only deletes the object in the\ndatabase; the Python instance will still exist and will still have data in\nits fields. This method returns the number of objects deleted and a dictionary\nwith the number of deletions per object type.
Untuk rincian lebih, termasuk bagaimana menghapus obyek-obyek dalam kumpulan, lihat menghapus obyek.
\nJika anda ingin menyesuaikan perilaku hapus, anda dapat menimpa metode delete(). Lihat Menimpa metode model yang detetapkan untuk lebih rinci.
Sometimes with multi-table inheritance you may\nwant to delete only a child model's data. Specifying keep_parents=True will\nkeep the parent model's data.
When you pickle a model, its current state is pickled. When you unpickle\nit, it'll contain the model instance at the moment it was pickled, rather than\nthe data that's currently in the database.
A few object methods have special purposes.
\n__str__()Link to this heading#The __str__() method is called whenever you call str() on an object.\nDjango uses str(obj) in a number of places. Most notably, to display an\nobject in the Django admin site and as the value inserted into a template when\nit displays an object. Thus, you should always return a nice, human-readable\nrepresentation of the model from the __str__() method.
Sebagai contoh:
\nfrom django.db import models\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n\n def __str__(self):\n return '%s %s' % (self.first_name, self.last_name)\n__eq__()Link to this heading#The equality method is defined such that instances with the same primary\nkey value and the same concrete class are considered equal, except that\ninstances with a primary key value of None aren't equal to anything except\nthemselves. For proxy models, concrete class is defined as the model's first\nnon-proxy parent; for all other models it's simply the model's class.
Sebagai contoh:
\nfrom django.db import models\n\nclass MyModel(models.Model):\n id = models.AutoField(primary_key=True)\n\nclass MyProxyModel(MyModel):\n class Meta:\n proxy = True\n\nclass MultitableInherited(MyModel):\n pass\n\n# Primary keys compared\nMyModel(id=1) == MyModel(id=1)\nMyModel(id=1) != MyModel(id=2)\n# Primary keys are None\nMyModel(id=None) != MyModel(id=None)\n# Same instance\ninstance = MyModel(id=None)\ninstance == instance\n# Proxy model\nMyModel(id=1) == MyProxyModel(id=1)\n# Multi-table inheritance\nMyModel(id=1) != MultitableInherited(id=1)\n__hash__()Link to this heading#The __hash__() method is based on the instance's primary key value. It\nis effectively hash(obj.pk). If the instance doesn't have a primary key\nvalue then a TypeError will be raised (otherwise the __hash__()\nmethod would return different values before and after the instance is\nsaved, but changing the __hash__() value of an instance is\nforbidden in Python.
get_absolute_url()Link to this heading#Define a get_absolute_url() method to tell Django how to calculate the\ncanonical URL for an object. To callers, this method should appear to return a\nstring that can be used to refer to the object over HTTP.
Sebagai contoh:
\ndef get_absolute_url(self):\n return "/people/%i/" % self.id\nWhile this code is correct and simple, it may not be the most portable way to\nto write this kind of method. The reverse() function is\nusually the best approach.
Sebagai contoh:
\ndef get_absolute_url(self):\n from django.urls import reverse\n return reverse('people.views.details', args=[str(self.id)])\nOne place Django uses get_absolute_url() is in the admin app. If an object\ndefines this method, the object-editing page will have a "View on site" link\nthat will jump you directly to the object's public view, as given by\nget_absolute_url().
Similarly, a couple of other bits of Django, such as the syndication feed\nframework, use get_absolute_url() when it is\ndefined. If it makes sense for your model's instances to each have a unique\nURL, you should define get_absolute_url().
It's good practice to use get_absolute_url() in templates, instead of\nhard-coding your objects' URLs. For example, this template code is bad:
<!-- BAD template code. Avoid! -->\n<a href="/people/{{ object.id }}/">{{ object.name }}</a>\nKode cetakan ini jauh lebih baik:
\n<a href="{{ object.get_absolute_url }}">{{ object.name }}</a>\nThe logic here is that if you change the URL structure of your objects, even\nfor something simple such as correcting a spelling error, you don't want to\nhave to track down every place that the URL might be created. Specify it once,\nin get_absolute_url() and have all your other code call that one place.
In addition to save(), delete(), a model object\nmight have some of the following methods:
For every field that has choices set, the\nobject will have a get_FOO_display() method, where FOO is the name of\nthe field. This method returns the "human-readable" value of the field.
Sebagai contoh:
\nfrom django.db import models\n\nclass Person(models.Model):\n SHIRT_SIZES = (\n ('S', 'Small'),\n ('M', 'Medium'),\n ('L', 'Large'),\n )\n name = models.CharField(max_length=60)\n shirt_size = models.CharField(max_length=2, choices=SHIRT_SIZES)\n>>> p = Person(name="Fred Flintstone", shirt_size="L")\n>>> p.save()\n>>> p.shirt_size\n'L'\n>>> p.get_shirt_size_display()\n'Large'\nFor every DateField and\nDateTimeField that does not have null=True, the object will have get_next_by_FOO() and\nget_previous_by_FOO() methods, where FOO is the name of the field. This\nreturns the next and previous object with respect to the date field, raising\na DoesNotExist exception when appropriate.
Both of these methods will perform their queries using the default\nmanager for the model. If you need to emulate filtering used by a\ncustom manager, or want to perform one-off custom filtering, both\nmethods also accept optional keyword arguments, which should be in the\nformat described in Field lookups.
\nNote that in the case of identical date values, these methods will use the\nprimary key as a tie-breaker. This guarantees that no records are skipped or\nduplicated. That also means you cannot use those methods on unsaved objects.
\nDoesNotExistLink to this heading#This exception is raised by the ORM in a couple places, for example by\nQuerySet.get() when an object\nis not found for the given query parameters.
Django provides a DoesNotExist exception as an attribute of each model\nclass to identify the class of object that could not be found and to allow\nyou to catch a particular model class with try/except. The exception is\na subclass of django.core.exceptions.ObjectDoesNotExist.