summaryrefslogtreecommitdiff
path: root/docs/ref/models
diff options
context:
space:
mode:
authorMalcolm Tredinnick <malcolm.tredinnick@gmail.com>2009-03-20 23:15:27 +0000
committerMalcolm Tredinnick <malcolm.tredinnick@gmail.com>2009-03-20 23:15:27 +0000
commit4eadcf45d4d3951cd674caebeee9c62712bef781 (patch)
tree57accbf7f478e4dfbb724c656fe08409f0c101a6 /docs/ref/models
parent6e3b129f158cfb6de991854c36cdc44cd3434bb1 (diff)
Added some further clarification to the docs for Meta.managed.
Not sure if any of these are noticed as omissions yet; it's too new. Primarily trying to head off questions in the future. git-svn-id: http://code.djangoproject.com/svn/django/trunk@10107 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs/ref/models')
-rw-r--r--docs/ref/models/options.txt28
1 files changed, 18 insertions, 10 deletions
diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt
index ebbb59559a..3ba5472bf9 100644
--- a/docs/ref/models/options.txt
+++ b/docs/ref/models/options.txt
@@ -82,24 +82,32 @@ See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
.. versionadded:: 1.1
+Defaults to ``True``, meaning Django will create the appropriate database
+tables in :ref:`django-admin-syncdb` and remove them as part of a :ref:`reset
+<django-admin-reset>` management command. That is, Django *manages* the
+database tables' lifecycles.
+
If ``False``, no database table creation or deletion operations will be
performed for this model. This is useful if the model represents an existing
-table or a database view that has been created by some other means.
+table or a database view that has been created by some other means. This is
+the *only* difference when ``managed`` is ``False``. All other aspects of
+model handling are exactly the same as normal. This includes
-The default value is ``True``, meaning Django will create the appropriate
-database tables in :ref:`django-admin-syncdb` and remove them as part of a
-:ref:`reset <django-admin-reset>` management command.
+ 1. Adding an automatic primary key field to the model if you don't declare
+ it. To avoid confusion for later code readers, it's recommended to
+ specify all the columns from the database table you are modeling when
+ using unmanaged models.
-If a model contains a :class:`~django.db.models.ManyToManyField` and has
-``managed=False``, the intermediate table for the many-to-many join will also
-not be created. Should you require the intermediate table to be created, set
-it up as an explicit model and use the :attr:`ManyToManyField.through`
-attribute.
+ 2. If a model contains a :class:`~django.db.models.ManyToManyField` and
+ has ``managed=False``, the intermediate table for the many-to-many join
+ will also not be created. Should you require the intermediate table to
+ be created, set it up as an explicit model and use the
+ :attr:`ManyToManyField.through` attribute.
For tests involving models with ``managed=False``, it's up to you to ensure
the correct tables are created as part of the test setup.
-If you're interested in changing the Python-level behaviour of a model class,
+If you're interested in changing the Python-level behavior of a model class,
you *could* use ``managed=False`` and create a copy of an existing model.
However, there's a better approach for that situation: :ref:`proxy-models`.