mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-04 10:59:45 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Small start to migrations documentation

Browse source
This commit is contained in:
Andrew Godwin 2013-07-25 14:45:38 +01:00
parent 00276e0414
commit 06103c8ef5
4 changed files with 164 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

86
docs/ref/django-admin.txt
View file

@ -572,6 +572,48 @@ Use the ``--keep-pot`` option to prevent django from deleting the temporary
.pot file it generates before creating the .po file. This is useful for
debugging errors which may prevent the final language files from being created.
makemigrations [<appname>]
--------------------------
.. django-admin:: makemigrations
Creates new migrations based on the changes detected to your models.
Migrations, their relationship with apps and more are covered in depth in
:doc:`the migrations documentation</topics/migrations>`.
Providing one or more app names as arguments will limit the migrations created
to the app specified and any dependencies needed (the table at the other end
of a ForeignKey, for example)
.. django-admin-option:: --empty
The ``--empty`` option will cause ``makemigrations`` to output an empty
migration for the specified apps, for manual editing. This option is only
for advanced users and should not be used unless you are familiar with
the migration format, migration operations and the dependencies between
your migrations.
migrate [<appname> [<migrationname>]]
-------------------------------------
.. django-admin:: migrate
Synchronises the database state with the current set of models and migrations.
Migrations, their relationship with apps and more are covered in depth in
:doc:`the migrations documentation</topics/migrations>`.
The behaviour of this command changes depending on the arguments provided:
* No arguments: All migrated apps have all of their migrations run,
and all unmigrated apps are synchronized with the database,
* ``<appname>``: The specified app has its migrations run, up to the most
recent migration. This may involve running other apps' migrations too, due
to dependencies.
* ``<appname> <migrationname>``: Brings the database schema to a state where it
would have just run the given migration, but no further - this may involve
unapplying migrations if you have previously migrated past the named
migration. Use the name `zero` to unapply all migrations for an app.
runfcgi [options]
-----------------
@ -1107,47 +1149,13 @@ syncdb
.. django-admin:: syncdb
Creates the database tables for all apps in :setting:`INSTALLED_APPS` whose
tables have not already been created.
.. deprecated:: 1.7
Use this command when you've added new applications to your project and want to
install them in the database. This includes any apps shipped with Django that
might be in :setting:`INSTALLED_APPS` by default. When you start a new project,
run this command to install the default apps.
This command has been deprecated in favour of the :djadmin:`migrate`
command, which performs both the old behaviour as well as executing
migrations. It is now just an alias to that command.
.. admonition:: Syncdb will not alter existing tables
``syncdb`` will only create tables for models which have not yet been
installed. It will *never* issue ``ALTER TABLE`` statements to match
changes made to a model class after installation. Changes to model classes
and database schemas often involve some form of ambiguity and, in those
cases, Django would have to guess at the correct changes to make. There is
a risk that critical data would be lost in the process.
If you have made changes to a model and wish to alter the database tables
to match, use the ``sql`` command to display the new SQL structure and
compare that to your existing table schema to work out the changes.
If you're installing the ``django.contrib.auth`` application, ``syncdb`` will
give you the option of creating a superuser immediately.
``syncdb`` will also search for and install any fixture named ``initial_data``
with an appropriate extension (e.g. ``json`` or ``xml``). See the
documentation for ``loaddata`` for details on the specification of fixture
data files.
The :djadminopt:`--noinput` option may be provided to suppress all user
prompts.
The :djadminopt:`--database` option can be used to specify the database to
synchronize.
--no-initial-data
~~~~~~~~~~~~~~~~~
.. versionadded:: 1.5
Use ``--no-initial-data`` to avoid loading the initial_data fixture.
Alias for :djadmin:`migrate`.
test <app or test identifier>
-----------------------------