Commit 4bbbf6cc authored by Russell Keith-Magee's avatar Russell Keith-Magee
Browse files

[1.1.X] Updated the docs to suggest using ``*args, **kwargs`` when...

[1.1.X] Updated the docs to suggest using ``*args, **kwargs`` when implementing model save methods. Thanks to Jeff Croft for the report.

Partial backport of r12118 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.1.X@12119 bcc190cf-cafb-0310-a4f2-bffc1f526a37
parent 3de16688
Loading
Loading
Loading
Loading
+16 −10
Original line number Diff line number Diff line
@@ -34,13 +34,15 @@ To save an object back to the database, call ``save()``:

.. method:: Model.save([force_insert=False, force_update=False])

Of course, there are some subtleties; see the sections below.

.. versionadded:: 1.0
   The ``force_insert`` and ``force_update`` arguments were added.

If you want customized saving behavior, you can override this
``save()`` method. See :ref:`overriding-model-methods` for more
details.

The signature of the ``save()`` method has changed from earlier versions
(``force_insert`` and ``force_update`` have been added). If you are overriding
these methods, be sure to use the correct signature.
The model save process also has some subtleties; see the sections
below.

Auto-incrementing primary keys
------------------------------
@@ -233,13 +235,17 @@ Deleting objects

.. method:: Model.delete()

   Issues a SQL ``DELETE`` for the object. This only deletes the object in the
   database; the Python instance will still be around, and will still have data
   in its fields.
Issues a SQL ``DELETE`` for the object. This only deletes the object
in the database; the Python instance will still be around, and will
still have data in its fields.

For more details, including how to delete objects in bulk, see
:ref:`topics-db-queries-delete`.

If you want customized deletion behavior, you can override this
``delete()`` method. See :ref:`overriding-model-methods` for more
details.

.. _model-instance-methods:

Other model instance methods
+19 −9
Original line number Diff line number Diff line
@@ -707,6 +707,8 @@ below -- but there are a couple that you'll almost always want to define:
        Any object that has a URL that uniquely identifies it should define this
        method.

.. _overriding-model-methods:

Overriding predefined model methods
-----------------------------------

@@ -726,9 +728,9 @@ to happen whenever you save an object. For example (see
        name = models.CharField(max_length=100)
        tagline = models.TextField()

        def save(self, force_insert=False, force_update=False):
        def save(self, *args, **kwargs):
            do_something()
            super(Blog, self).save(force_insert, force_update) # Call the "real" save() method.
            super(Blog, self).save(*args, **kwargs) # Call the "real" save() method.
            do_something_else()

You can also prevent saving::
@@ -737,16 +739,24 @@ You can also prevent saving::
        name = models.CharField(max_length=100)
        tagline = models.TextField()

        def save(self, force_insert=False, force_update=False):
        def save(self, *args, **kwargs):
            if self.name == "Yoko Ono's blog":
                return # Yoko shall never have her own blog!
            else:
                super(Blog, self).save(force_insert, force_update) # Call the "real" save() method.

It's important to remember to call the superclass method -- that's that
``super(Blog, self).save()`` business -- to ensure that the object still gets
saved into the database. If you forget to call the superclass method, the
default behavior won't happen and the database won't get touched.
                super(Blog, self).save(*args, **kwargs) # Call the "real" save() method.

It's important to remember to call the superclass method -- that's
that ``super(Blog, self).save(*args, **kwargs)`` business -- to ensure
that the object still gets saved into the database. If you forget to
call the superclass method, the default behavior won't happen and the
database won't get touched.

It's also important that you pass through the arguments that can be
passed to the model method -- that's what the ``*args, **kwargs`` bit
does. Django will, from time to time, extend the capabilities of
built-in model methods, adding new arguments. If you use ``*args,
**kwargs`` in your method definitions, you are guaranteed that your
code will automatically support those arguments when they are added.

Executing custom SQL
--------------------