Fixed #22322 -- Fixed incorrect explanation of what managed=False does.

refs #14305.

Thanks Adrian Klaver for the report.
This commit is contained in:
Tim Graham 2014-03-25 10:17:23 -04:00
parent 69d4b1c3ea
commit 9b7ba8af1b
3 changed files with 13 additions and 26 deletions

View File

@ -42,7 +42,7 @@ class Command(NoArgsCommand):
yield "# You'll have to do the following manually to clean this up:"
yield "# * Rearrange models' order"
yield "# * Make sure each model has one field with primary_key=True"
yield "# * Remove `managed = False` lines for those models you wish to give write DB access"
yield "# * Remove `managed = False` lines if you wish to allow Django to create, modify, and delete the table"
yield "# Feel free to rename the models, but don't rename db_table values or field names."
yield "#"
yield "# Also note: You'll have to insert the output of 'django-admin.py sqlcustom [app_label]'"

View File

@ -49,16 +49,9 @@ Once you've cleaned up your models, name the file ``models.py`` and put it in
the Python package that holds your app. Then add the app to your
:setting:`INSTALLED_APPS` setting.
If your plan is that your Django application(s) modify data (i.e. edit, remove
records and create new ones) in the existing database tables corresponding to
any of the introspected models then one of the manual review and edit steps
you need to perform on the resulting ``models.py`` file is to change the
Python declaration of each one of these models to specify it is a
:attr:`managed <django.db.models.Options.managed>` one. For example, consider
this generated model definition:
.. code-block:: python
:emphasize-lines: 5
By default, :djadmin:`inspectdb` creates unmanaged models. That is,
``managed = False`` in the model's ``Meta`` class tells Django not to manage
each table's creation, modification, and deletion::
class Person(models.Model):
id = models.IntegerField(primary_key=True)
@ -67,12 +60,9 @@ this generated model definition:
managed = False
db_table = 'CENSUS_PERSONS'
If you wanted to modify existing data on your ``CENSUS_PERSONS`` SQL table
with Django you'd need to change the ``managed`` option highlighted above to
``True`` (or simply remove it to let it because ``True`` is its default value).
This serves as an explicit opt-in to give your nascent Django project write
access to your precious data on a model by model basis.
If you do want to allow Django to manage the table's lifecycle, you'll need to
change the :attr:`~django.db.models.Options.managed` option above to ``True``
(or simply remove it because ``True`` is its default value).
Install the core Django tables
==============================

View File

@ -347,15 +347,12 @@ needed.
``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection
only works in PostgreSQL and with certain types of MySQL tables.
If your plan is that your Django application(s) modify data (i.e. edit, remove
records and create new ones) in the existing database tables corresponding to
any of the introspected models then one of the manual review and edit steps
you need to perform on the resulting ``models.py`` file is to change the
Python declaration of each one of these models to specify it is a
:attr:`managed <django.db.models.Options.managed>` one.
This serves as an explicit opt-in to give your nascent Django project write
access to your precious data on a model by model basis.
By default, ``inspectdb`` creates unmanaged models. That is, ``managed = False``
in the model's ``Meta`` class tells Django not to manage each table's creation,
modification, and deletion. If you do want to allow Django to manage the
table's lifecycle, you'll need to change the
:attr:`~django.db.models.Options.managed` option to ``True`` (or simply remove
it because ``True`` is its default value).
The :djadminopt:`--database` option may be used to specify the
database to introspect.