Acuan contoh modelLink to this heading#

Menyesuaikan memuat modelLink to this heading#

classmethod Model.from_db(db, field_names, values)Link to this definition#

The from_db() method can be used to customize model instance creation when loading from the database.

The db argument contains the database alias for the database the model is loaded from, field_names contains the names of all loaded fields, and values contains the loaded values for each field in field_names. The field_names are in the same order as the values. If all of the model's fields are present, then values are guaranteed to be in the order __init__() expects them. That is, the instance can be created by cls(*values). If any fields are deferred, they won't appear in field_names. In that case, assign a value of django.db.models.DEFERRED to each of the missing fields.

In addition to creating the new model, the from_db() method must set the adding and db flags in the new instance's _state attribute.

Below is an example showing how to record the initial values of fields that are loaded from the database:

from django.db.models import DEFERRED

@classmethod
def from_db(cls, db, field_names, values):
    # Default implementation of from_db() (subject to change and could
    # be replaced with super()).
    if len(values) != len(cls._meta.concrete_fields):
        values = list(values)
        values.reverse()
        values = [
            values.pop() if f.attname in field_names else DEFERRED
            for f in cls._meta.concrete_fields
        ]
    instance = cls(*values)
    instance._state.adding = False
    instance._state.db = db
    # customization to store the original field values on the instance
    instance._loaded_values = dict(zip(field_names, values))
    return instance

def save(self, *args, **kwargs):
    # Check how the current values differ from ._loaded_values. For example,
    # prevent changing the creator_id of the model. (This example doesn't
    # support cases where 'creator_id' is deferred).
    if not self._state.adding and (
            self.creator_id != self._loaded_values['creator_id']):
        raise ValueError("Updating the value of creator isn't allowed")
    super().save(*args, **kwargs)

The example above shows a full from_db() implementation to clarify how that is done. In this case it would of course be possible to use super() call in the from_db() method.

Peningkatan-otomatis primary keyLink to this heading#

Jika 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.')
>>> b2.id     # Returns None, because b2 doesn't have an ID yet.
>>> b2.save()
>>> b2.id     # Returns the ID of your new object.

There's no way to tell what the value of an ID will be before you call save(), 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.

>>> b3 = Blog(id=3, name='Cheddar Talk', tagline='Thoughts on cheese.')
>>> b3.id     # Returns 3.
>>> b3.save()
>>> b3.id     # Returns 3.

b4 = Blog(id=3, name='Not Cheddar', tagline='Anything but cheese.')
b4.save()  # Overrides the previous blog with ID=3!

Apa yang terjadi ketika anda menyimpan?Link to this heading#

Ketika anda menyimpan sebuah obyek, Django melakukan langkah-langkah berikut:

1. Emit a pre-save signal. The pre_save signal is sent, allowing any functions listening for that signal to do something.

2. Preprocess the data. Each field's pre_save() method is called to perform any automated data modification that's needed. For example, the date/time fields override pre_save() to implement auto_now_add and auto_now.

3. Prepare the data for the database. Each field's get_db_prep_save() method is asked to provide its 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 integers and strings, are 'ready to write' as a Python object. However, more complex data types often require some modification.

   For example, DateField fields use a Python datetime object to store data. Databases don't store datetime objects, so the field value must be converted into an ISO-compliant date string for insertion into the database.

4. Insert the data into the database. The preprocessed, prepared data is composed into an SQL statement for insertion into the database.

5. Emit a post-save signal. The post_save signal is sent, allowing any functions listening for that signal to do something.

Bagaimana Django mengetahui untuk UPDATE lawan INSERTLink to this heading#

You may have noticed Django database objects use the same save() method for creating and changing objects. Django abstracts the need to use INSERT or UPDATE SQL statements. Specifically, when you call save() and the object's primary key attribute does not define a default, Django follows this algorithm:

• If the object's primary key attribute is set to a value that evaluates to True (i.e., a value other than None or the empty string), Django executes an UPDATE.

• If the object's primary key attribute is not set or if the UPDATE didn't update anything (e.g. if primary key is set to a value that doesn't exist in the database), Django executes an INSERT.

If the object's primary key attribute defines a default then Django executes an UPDATE if it is an existing model instance and primary key is set to a value that exists in the database. Otherwise, Django executes an INSERT.

The one gotcha here is that you should be careful not to specify a primary-key value explicitly when saving new objects, if you cannot guarantee the primary-key value is unused. For more on this nuance, see Explicitly specifying auto-primary-key values above and Forcing an INSERT or UPDATE below.

In Django 1.5 and earlier, Django did a SELECT when the primary key attribute was set. If the SELECT found a row, then Django did an UPDATE, otherwise it did an INSERT. The old algorithm results in one more query in the UPDATE case. There are some rare cases where the database doesn't report that a row was updated even if the database contains a row for the object's primary key value. An example is the PostgreSQL ON UPDATE trigger which returns NULL. In such cases it is possible to revert to the old algorithm by setting the select_on_save option to True.

Memperbaharui atribut berdasarkan pada bidang yang adaLink to this heading#

Sometimes you'll need to perform a simple arithmetic task on a field, such as incrementing or decrementing the current value. The obvious way to achieve this is to do something like:

>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')
>>> product.number_sold += 1
>>> product.save()

If the old number_sold value retrieved from the database was 10, then the 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 the update relative to the original field value, rather than as an explicit assignment of a new value. Django provides F expressions for performing this kind of relative update. Using F expressions, the previous example is expressed as:

>>> from django.db.models import F
>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')
>>> product.number_sold = F('number_sold') + 1
>>> product.save()

For more details, see the documentation on F expressions and their use in update queries.

Menentukan bidang-bidang mana yang disimpanLink to this heading#

If save() is passed a list of field names in keyword argument update_fields, only the fields named in that list will be updated. This may be desirable if you want to update just one or a few fields on an object. There will be a slight performance benefit from preventing all of the model fields from being updated in the database. For example:

product.name = 'Name changed again'
product.save(update_fields=['name'])

The update_fields argument can be any iterable containing strings. An empty update_fields iterable will skip the save. A value of None will perform an update on all fields.

Menentukan update_fields akan memaksa sebuah pembaharuan.

When saving a model fetched through deferred model loading (only() or defer()) only the fields loaded from the DB will get updated. In effect there is an automatic update_fields in this case. If you assign or change any deferred field value, the field will be added to the updated fields.

__str__()Link to this heading#

Model.__str__()Link to this definition#

The __str__() method is called whenever you call str() on an object. Django uses str(obj) in a number of places. Most notably, to display an object in the Django admin site and as the value inserted into a template when it displays an object. Thus, you should always return a nice, human-readable representation of the model from the __str__() method.

Sebagai contoh:

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)

    def __str__(self):
        return '%s %s' % (self.first_name, self.last_name)

__eq__()Link to this heading#

Model.__eq__()Link to this definition#

The equality method is defined such that instances with the same primary key value and the same concrete class are considered equal, except that instances with a primary key value of None aren't equal to anything except themselves. For proxy models, concrete class is defined as the model's first non-proxy parent; for all other models it's simply the model's class.

Sebagai contoh:

from django.db import models

class MyModel(models.Model):
    id = models.AutoField(primary_key=True)

class MyProxyModel(MyModel):
    class Meta:
        proxy = True

class MultitableInherited(MyModel):
    pass

# Primary keys compared
MyModel(id=1) == MyModel(id=1)
MyModel(id=1) != MyModel(id=2)
# Primary keys are None
MyModel(id=None) != MyModel(id=None)
# Same instance
instance = MyModel(id=None)
instance == instance
# Proxy model
MyModel(id=1) == MyProxyModel(id=1)
# Multi-table inheritance
MyModel(id=1) != MultitableInherited(id=1)

__hash__()Link to this heading#

Model.__hash__()Link to this definition#

The __hash__() method is based on the instance's primary key value. It is effectively hash(obj.pk). If the instance doesn't have a primary key value then a TypeError will be raised (otherwise the __hash__() method would return different values before and after the instance is saved, but changing the __hash__() value of an instance is forbidden in Python.

get_absolute_url()Link to this heading#

Model.get_absolute_url()Link to this definition#

Define a get_absolute_url() method to tell Django how to calculate the canonical URL for an object. To callers, this method should appear to return a string that can be used to refer to the object over HTTP.

Sebagai contoh:

def get_absolute_url(self):
    return "/people/%i/" % self.id

While this code is correct and simple, it may not be the most portable way to to write this kind of method. The reverse() function is usually the best approach.

Sebagai contoh:

def get_absolute_url(self):
    from django.urls import reverse
    return reverse('people.views.details', args=[str(self.id)])

One place Django uses get_absolute_url() is in the admin app. If an object defines this method, the object-editing page will have a "View on site" link that will jump you directly to the object's public view, as given by get_absolute_url().

Similarly, a couple of other bits of Django, such as the syndication feed framework, use get_absolute_url() when it is defined. If it makes sense for your model's instances to each have a unique URL, you should define get_absolute_url().

It's good practice to use get_absolute_url() in templates, instead of hard-coding your objects' URLs. For example, this template code is bad:

<!-- BAD template code. Avoid! -->
<a href="/people/{{ object.id }}/">{{ object.name }}</a>

Kode cetakan ini jauh lebih baik:

<a href="{{ object.get_absolute_url }}">{{ object.name }}</a>

The logic here is that if you change the URL structure of your objects, even for something small like correcting a spelling error, you don't want to have to track down every place that the URL might be created. Specify it once, in get_absolute_url() and have all your other code call that one place.

_stateLink to this heading#

Model._stateLink to this definition#

The _state attribute refers to a ModelState object that tracks the lifecycle of the model instance.

The ModelState object has two attributes: adding, a flag which is True if the model has not been saved to the database yet, and db, a string referring to the database alias the instance was loaded from or saved to.

Newly instantiated instances have adding=True and db=None, since they are yet to be saved. Instances fetched from a QuerySet will have adding=False and db set to the alias of the associated database.