diff --git a/django/core/management/__init__.py b/django/core/management/__init__.py index 0254dcbefea..ed4323ecd01 100644 --- a/django/core/management/__init__.py +++ b/django/core/management/__init__.py @@ -81,7 +81,7 @@ def call_command(name, *args, **options): This is the primary API you should use for calling specific commands. Some examples: - call_command('syncdb') + call_command('migrate') call_command('shell', plain=True) call_command('sqlmigrate', 'myapp') """ diff --git a/django/core/management/commands/syncdb.py b/django/core/management/commands/syncdb.py deleted file mode 100644 index b89ad62c3ec..00000000000 --- a/django/core/management/commands/syncdb.py +++ /dev/null @@ -1,45 +0,0 @@ -import warnings - -from django.apps import apps -from django.contrib.auth import get_user_model -from django.db import DEFAULT_DB_ALIAS -from django.core.management import call_command -from django.core.management.base import BaseCommand -from django.utils.deprecation import RemovedInDjango19Warning -from django.utils.six.moves import input - - -class Command(BaseCommand): - help = "Deprecated - use 'migrate' instead." - - def add_arguments(self, parser): - parser.add_argument('--noinput', action='store_false', dest='interactive', default=True, - help='Tells Django to NOT prompt the user for input of any kind.') - parser.add_argument('--no-initial-data', action='store_false', dest='load_initial_data', default=True, - help='Tells Django not to load any initial data after database synchronization.') - parser.add_argument('--database', default=DEFAULT_DB_ALIAS, - help='Nominates a database to synchronize. Defaults to the "default" database.') - - def handle(self, **options): - warnings.warn("The syncdb command will be removed in Django 1.9", RemovedInDjango19Warning) - call_command("migrate", **options) - - try: - apps.get_model('auth', 'Permission') - except LookupError: - return - - UserModel = get_user_model() - - if not UserModel._default_manager.exists() and options.get('interactive'): - msg = ("\nYou have installed Django's auth system, and " - "don't have any superusers defined.\nWould you like to create one " - "now? (yes/no): ") - confirm = input(msg) - while 1: - if confirm not in ('yes', 'no'): - confirm = input('Please enter either "yes" or "no": ') - continue - if confirm == 'yes': - call_command("createsuperuser", interactive=True, database=options['database']) - break diff --git a/django/db/backends/base/schema.py b/django/db/backends/base/schema.py index 4a63088d30f..17a7a0d458c 100644 --- a/django/db/backends/base/schema.py +++ b/django/db/backends/base/schema.py @@ -24,7 +24,7 @@ class BaseDatabaseSchemaEditor(object): It is intended to eventually completely replace DatabaseCreation. This class should be used by creating an instance for each set of schema - changes (e.g. a syncdb run, a migration file), and by first calling start(), + changes (e.g. a migration file), and by first calling start(), then the relevant actions, and then commit(). This is necessary to allow things like circular foreign key references - FKs will only be created once commit() is called. diff --git a/django/db/migrations/recorder.py b/django/db/migrations/recorder.py index 923048f58df..d1071cecb77 100644 --- a/django/db/migrations/recorder.py +++ b/django/db/migrations/recorder.py @@ -11,7 +11,7 @@ class MigrationRecorder(object): Deals with storing migration records in the database. Because this table is actually itself used for dealing with model - creation, it's the one thing we can't do normally via syncdb or migrations. + creation, it's the one thing we can't do normally via migrations. We manually handle table creation/schema updating (using schema backend) and then have a floating model to do queries with. diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index d343a19205f..728432eecca 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -751,10 +751,6 @@ The behavior of this command changes depending on the arguments provided: migrated past the named migration. Use the name ``zero`` to unapply all migrations for an app. -Unlike ``syncdb``, this command does not prompt you to create a superuser if -one doesn't exist (assuming you are using :mod:`django.contrib.auth`). Use -:djadmin:`createsuperuser` to do that if you wish. - The :djadminopt:`--database` option can be used to specify the database to migrate. @@ -1264,19 +1260,6 @@ for :djadmin:`startapp`. .. _`template source`: https://github.com/django/django/tree/master/django/conf/project_template/ -syncdb ------- - -.. django-admin:: syncdb - -.. deprecated:: 1.7 - - This command has been deprecated in favor of the :djadmin:`migrate` - command, which performs both the old behavior as well as executing - migrations. It is now just an alias to that command. - -Alias for :djadmin:`migrate`. - test ----------------------------- diff --git a/docs/releases/1.1.txt b/docs/releases/1.1.txt index 38212615cc2..c58a7c5fe55 100644 --- a/docs/releases/1.1.txt +++ b/docs/releases/1.1.txt @@ -224,7 +224,7 @@ A number of features have been added to Django's model layer: You can now control whether or not Django manages the life-cycle of the database tables for a model using the :attr:`~Options.managed` model option. This defaults to ``True``, meaning that Django will create the appropriate database -tables in :djadmin:`syncdb` and remove them as part of the ``reset`` +tables in ``syncdb`` and remove them as part of the ``reset`` command. That is, Django *manages* the database table's lifecycle. If you set this to ``False``, however, no database table creating or deletion diff --git a/docs/releases/1.2.5.txt b/docs/releases/1.2.5.txt index 9913490dcf1..5d3050a9932 100644 --- a/docs/releases/1.2.5.txt +++ b/docs/releases/1.2.5.txt @@ -105,7 +105,7 @@ the policy that data inserted by custom SQL will *not* be visible during testing. This change only affects the testing process. You can still use custom -SQL to load data into your production database as part of the syncdb +SQL to load data into your production database as part of the ``syncdb`` process. If you require data to exist during test conditions, you should either insert it using :ref:`test fixtures `, or using the ``setUp()`` method of your diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt index 6b947a16e7b..96c0315a762 100644 --- a/docs/releases/1.3.txt +++ b/docs/releases/1.3.txt @@ -553,7 +553,7 @@ the policy that data inserted by custom SQL will *not* be visible during testing. This change only affects the testing process. You can still use custom -SQL to load data into your production database as part of the syncdb +SQL to load data into your production database as part of the ``syncdb`` process. If you require data to exist during test conditions, you should either insert it using :ref:`test fixtures `, or using the ``setUp()`` method of your diff --git a/docs/releases/1.5.txt b/docs/releases/1.5.txt index 3f07cf68604..8838f1983dd 100644 --- a/docs/releases/1.5.txt +++ b/docs/releases/1.5.txt @@ -627,16 +627,16 @@ with the :meth:`~django.forms.Form.is_valid()` method and not with the presence or absence of the :attr:`~django.forms.Form.cleaned_data` attribute on the form. -Behavior of :djadmin:`syncdb` with multiple databases -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Behavior of ``syncdb`` with multiple databases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -:djadmin:`syncdb` now queries the database routers to determine if content +``syncdb`` now queries the database routers to determine if content types (when :mod:`~django.contrib.contenttypes` is enabled) and permissions (when :mod:`~django.contrib.auth` is enabled) should be created in the target database. Previously, it created them in the default database, even when another database was specified with the :djadminopt:`--database` option. -If you use :djadmin:`syncdb` on multiple databases, you should ensure that +If you use ``syncdb`` on multiple databases, you should ensure that your routers allow synchronizing content types and permissions to only one of them. See the docs on the :ref:`behavior of contrib apps with multiple databases ` for more information. diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt index bdf9abe3a20..bca0aa35a9a 100644 --- a/docs/releases/1.7.txt +++ b/docs/releases/1.7.txt @@ -953,8 +953,8 @@ Backwards incompatible changes in 1.7 deprecation timeline for a given feature, its removal may appear as a backwards incompatible change. -allow_syncdb/allow_migrate -~~~~~~~~~~~~~~~~~~~~~~~~~~ +``allow_syncdb`` / ``allow_migrate`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ While Django will still look at ``allow_syncdb`` methods even though they should be renamed to ``allow_migrate``, there is a subtle difference in which @@ -1567,7 +1567,7 @@ submodules and the ``django.contrib.contenttypes.generic`` module is deprecated: ``syncdb`` ~~~~~~~~~~ -The :djadmin:`syncdb` command has been deprecated in favor of the new :djadmin:`migrate` +The ``syncdb`` command has been deprecated in favor of the new :djadmin:`migrate` command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few more, so it's safe to just change the name you're calling and nothing else. diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist index 5b8d89330c6..26bb3a5a659 100644 --- a/docs/spelling_wordlist +++ b/docs/spelling_wordlist @@ -630,7 +630,6 @@ subwidgets symlink symlinking symlinks -syncdb sysadmin systemwide tablespace diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt index 1220b4b41f4..e1d13457b7e 100644 --- a/docs/topics/migrations.txt +++ b/docs/topics/migrations.txt @@ -12,17 +12,6 @@ Migrations are Django's way of propagating changes you make to your models designed to be mostly automatic, but you'll need to know when to make migrations, when to run them, and the common problems you might run into. -A Brief History ---------------- - -Prior to version 1.7, Django only supported adding new models to the -database; it was not possible to alter or remove existing models via the -``syncdb`` command (the predecessor to :djadmin:`migrate`). - -Third-party tools, most notably `South `_, -provided support for these additional types of change, but it was considered -important enough that support was brought into core Django. - The Commands ------------ @@ -157,8 +146,7 @@ database to make sure they work as expected:: Running migrations: Applying books.0003_auto... OK -The command runs in two stages; first, it synchronizes unmigrated apps -(performing the same functionality that ``syncdb`` used to provide), and +The command runs in two stages; first, it synchronizes unmigrated apps, and then it runs any migrations that have not yet been applied. Once the migration is applied, commit the migration and the models change