p15693087
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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
This commit is contained in:
Malcolm Tredinnick 2009-03-20 23:15:27 +00:00
parent 6e3b129f15
commit 4eadcf45d4
1 changed files with 18 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/ref/models/options.txt
View File

@ -82,24 +82,32 @@ See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
.. versionadded:: 1.1 .. 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 If ``False``, no database table creation or deletion operations will be
performed for this model. This is useful if the model represents an existing 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 1. Adding an automatic primary key field to the model if you don't declare
database tables in :ref:`django-admin-syncdb` and remove them as part of a it. To avoid confusion for later code readers, it's recommended to
:ref:`reset <django-admin-reset>` management command. 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 2. If a model contains a :class:`~django.db.models.ManyToManyField` and
``managed=False``, the intermediate table for the many-to-many join will also has ``managed=False``, the intermediate table for the many-to-many join
not be created. Should you require the intermediate table to be created, set will also not be created. Should you require the intermediate table to
it up as an explicit model and use the :attr:`ManyToManyField.through` be created, set it up as an explicit model and use the
attribute. :attr:`ManyToManyField.through` attribute.
For tests involving models with ``managed=False``, it's up to you to ensure 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. 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. 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`. However, there's a better approach for that situation: :ref:`proxy-models`.