Fixed #21479 -- Favor 'migrate' over 'syncdb' in the docs.

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?

------------------------------------------------------

        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

-------------------------------------------

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

--------------------------------

==========================

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.

.. 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

    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:

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 </ref/django-admin>` for full

        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