diff --git a/docs/faq/models.txt b/docs/faq/models.txt index 97732131f0..eb2bb621dd 100644 --- a/docs/faq/models.txt +++ b/docs/faq/models.txt @@ -45,7 +45,7 @@ Take a look at Django's support for :mod:`schema migrations If you don't mind clearing data, your project's ``manage.py`` utility has a :djadmin:`flush` option to reset the database to the state it was in -immediately after :djadmin:`syncdb` was executed. +immediately after :djadmin:`migrate` was executed. Do Django models support multiple-column primary keys? ------------------------------------------------------ diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt index 0692e97156..23a1972a7e 100644 --- a/docs/howto/custom-model-fields.txt +++ b/docs/howto/custom-model-fields.txt @@ -676,8 +676,9 @@ For example:: def get_internal_type(self): return 'CharField' -No matter which database backend we are using, this will mean that ``syncdb`` -and other SQL commands create the right column type for storing a string. +No matter which database backend we are using, this will mean that +:djadmin:`migrate` and other SQL commands create the right column type for +storing a string. If :meth:`.get_internal_type` returns a string that is not known to Django for the database backend you are using -- that is, it doesn't appear in diff --git a/docs/howto/initial-data.txt b/docs/howto/initial-data.txt index 70d1ae18a6..61885a0803 100644 --- a/docs/howto/initial-data.txt +++ b/docs/howto/initial-data.txt @@ -78,9 +78,9 @@ Automatically loading initial data fixtures ------------------------------------------- If you create a fixture named ``initial_data.[xml/yaml/json]``, that fixture will -be loaded every time you run :djadmin:`syncdb`. This is extremely convenient, +be loaded every time you run :djadmin:`migrate`. This is extremely convenient, but be careful: remember that the data will be refreshed *every time* you run -:djadmin:`syncdb`. So don't use ``initial_data`` for data you'll want to edit. +:djadmin:`migrate`. So don't use ``initial_data`` for data you'll want to edit. Where Django finds fixture files -------------------------------- @@ -104,7 +104,7 @@ Providing initial SQL data ========================== Django provides a hook for passing the database arbitrary SQL that's executed -just after the CREATE TABLE statements when you run :djadmin:`syncdb`. You can +just after the CREATE TABLE statements when you run :djadmin:`migrate`. You can use this hook to populate default records, or you could also create SQL functions, views, triggers, etc. diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt index 8ddfc96edc..957876baa2 100644 --- a/docs/intro/tutorial01.txt +++ b/docs/intro/tutorial01.txt @@ -263,9 +263,9 @@ that, run the following command: .. code-block:: bash - $ python manage.py syncdb + $ python manage.py migrate -The :djadmin:`syncdb` command looks at the :setting:`INSTALLED_APPS` setting +The :djadmin:`migrate` command looks at the :setting:`INSTALLED_APPS` setting and creates any necessary database tables according to the database settings in your :file:`mysite/settings.py` file. You'll see a message for each database table it creates, and you'll get a prompt asking you if you'd like to @@ -281,8 +281,8 @@ display the tables Django created. Like we said above, the default applications are included for the common case, but not everybody needs them. If you don't need any or all of them, feel free to comment-out or delete the appropriate line(s) from - :setting:`INSTALLED_APPS` before running :djadmin:`syncdb`. The - :djadmin:`syncdb` command will only create tables for apps in + :setting:`INSTALLED_APPS` before running :djadmin:`migrate`. The + :djadmin:`migrate` command will only create tables for apps in :setting:`INSTALLED_APPS`. .. _creating-models: @@ -510,17 +510,17 @@ If you're interested, also run the following commands: Looking at the output of those commands can help you understand what's actually happening under the hood. -Now, run :djadmin:`syncdb` again to create those model tables in your database: +Now, run :djadmin:`migrate` again to create those model tables in your database: .. code-block:: bash - $ python manage.py syncdb + $ python manage.py migrate -The :djadmin:`syncdb` command runs the SQL from :djadmin:`sqlall` on your +The :djadmin:`migrate` command runs the SQL from :djadmin:`sqlall` on your database for all apps in :setting:`INSTALLED_APPS` that don't already exist in your database. This creates all the tables, initial data and indexes for any -apps you've added to your project since the last time you ran syncdb. -:djadmin:`syncdb` can be called as often as you like, and it will only ever +apps you've added to your project since the last time you ran :djadmin:`migrate`. +:djadmin:`migrate` can be called as often as you like, and it will only ever create the tables that don't exist. Read the :doc:`django-admin.py documentation ` for full diff --git a/docs/ref/contrib/gis/layermapping.txt b/docs/ref/contrib/gis/layermapping.txt index 381c7df133..376c6115b1 100644 --- a/docs/ref/contrib/gis/layermapping.txt +++ b/docs/ref/contrib/gis/layermapping.txt @@ -52,7 +52,7 @@ Example PRIMEM["Greenwich",0], UNIT["Degree",0.017453292519943295]] -2. Now we define our corresponding Django model (make sure to use ``syncdb``):: +2. Now we define our corresponding Django model (make sure to use :djadmin:`migrate`):: from django.contrib.gis.db import models diff --git a/docs/ref/contrib/gis/tutorial.txt b/docs/ref/contrib/gis/tutorial.txt index 99a4814f3d..17ce1edbf0 100644 --- a/docs/ref/contrib/gis/tutorial.txt +++ b/docs/ref/contrib/gis/tutorial.txt @@ -262,8 +262,8 @@ argument. Use an integer representing the coordinate system's EPSG code. __ http://en.wikipedia.org/wiki/SRID -Run ``syncdb`` --------------- +Run ``migrate`` +--------------- After defining your model, you need to sync it with the database. First, let's look at the SQL that will generate the table for the @@ -296,14 +296,14 @@ This command should produce the following output: CREATE INDEX "world_worldborder_mpoly_id" ON "world_worldborder" USING GIST ( "mpoly" GIST_GEOMETRY_OPS ); COMMIT; -If this looks correct, run ``syncdb`` to create this table in the database:: +If this looks correct, run :djadmin:`migrate` to create this table in the database:: - $ python manage.py syncdb + $ python manage.py migrate Creating table world_worldborder Installing custom SQL for world.WorldBorder model -The ``syncdb`` command may also prompt you to create an admin user. Either -do so now, or later by running ``django-admin.py createsuperuser``. +The :djadmin:`migrate` command may also prompt you to create an admin user. +Either do so now, or later by running ``django-admin.py createsuperuser``. Importing Spatial Data ====================== @@ -742,7 +742,7 @@ Start up the Django development server: $ python manage.py runserver Finally, browse to ``http://localhost:8000/admin/``, and log in with the admin -user created after running ``syncdb``. Browse to any of the ``WorldBorder`` +user created after running :djadmin:`migrate`. Browse to any of the ``WorldBorder`` entries -- the borders may be edited by clicking on a polygon and dragging the vertexes to the desired position. diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt index 22ced5fe7d..c1bf34ba86 100644 --- a/docs/ref/models/options.txt +++ b/docs/ref/models/options.txt @@ -263,7 +263,7 @@ Django quotes column and table names behind the scenes. Defaults to ``('add', 'change', 'delete')``. You may customize this list, for example, by setting this to an empty list if your app doesn't require any of the default permissions. It must be specified on the model before - the model is created by :djadmin:`syncdb` in order to prevent any omitted + the model is created by :djadmin:`migrate` in order to prevent any omitted permissions from being created. ``proxy`` diff --git a/docs/topics/db/multi-db.txt b/docs/topics/db/multi-db.txt index 51a1028342..a60bcc844f 100644 --- a/docs/topics/db/multi-db.txt +++ b/docs/topics/db/multi-db.txt @@ -73,14 +73,14 @@ If you attempt to access a database that you haven't defined in your Synchronizing your databases ============================ -The :djadmin:`syncdb` management command operates on one database at a +The :djadmin:`migrate` management command operates on one database at a time. By default, it operates on the ``default`` database, but by -providing a :djadminopt:`--database` argument, you can tell syncdb to -synchronize a different database. So, to synchronize all models onto +providing a :djadminopt:`--database` argument, you can tell :djadmin:`migrate` +to synchronize a different database. So, to synchronize all models onto all databases in our example, you would need to call:: - $ ./manage.py syncdb - $ ./manage.py syncdb --database=users + $ ./manage.py migrate + $ ./manage.py migrate --database=users If you don't want every application to be synchronized onto a particular database, you can define a :ref:`database @@ -97,7 +97,7 @@ Using other management commands ------------------------------- The other ``django-admin.py`` commands that interact with the database -operate in the same way as :djadmin:`syncdb` -- they only ever operate +operate in the same way as :djadmin:`migrate` -- they only ever operate on one database at a time, using :djadminopt:`--database` to control the database used. @@ -681,7 +681,7 @@ how you can split these models across databases: in the same database as ``sites``. In addition, some objects are automatically created just after -:djadmin:`syncdb` creates a table to hold them in a database: +:djadmin:`migrate` creates a table to hold them in a database: - a default ``Site``, - a ``ContentType`` for each model (including those not stored in that @@ -693,7 +693,7 @@ For common setups with multiple databases, it isn't useful to have these objects in more than one database. Common setups include master / slave and connecting to external databases. Therefore, it's recommended: -- either to run :djadmin:`syncdb` only for the default database; +- either to run :djadmin:`migrate` only for the default database; - or to write :ref:`database router` that allows synchronizing these three models only to one database. diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt index c221702005..a0bed1b2ee 100644 --- a/docs/topics/testing/overview.txt +++ b/docs/topics/testing/overview.txt @@ -1241,7 +1241,7 @@ Here's specifically what will happen: * At the start of each test case, before ``setUp()`` is run, Django will flush the database, returning the database to the state it was in - directly after :djadmin:`syncdb` was called. + directly after :djadmin:`migrate` was called. * Then, all the named fixtures are installed. In this example, Django will install any JSON fixture named ``mammals``, followed by any fixture named