Every Django project automatically generates a manage.py file. manage.py is a simple wrapper around django-admin; its job is to put the Django Project into the sys.path directory and set the DJANGO_SETTINGS_MODULE environment variable to the current Project’s settings.py file. In other words, the difference between django-admin and manage is that manage sets the project’s environment variables.

1. Usage Format

1
2

django-admin [command] [options]
manage.py [command] [options]

2. A Brief Introduction to the manage Commands

2.1 Creating a project - startproject

1

manage startproject pro_name

2.2 Creating an app - startapp

1

manage startapp app_name

2.3 Interactive environment - shell

1

manage shell

If IPython or bpython is installed, it will be designated as the interpreter interface.

2.4 Creating models - syncdb

manage syncdb

2.5 Starting the server - runserver

manage runserver [IP地址 : 端口号]

Starts a lightweight Web server locally

2.6 Determining the version you are using - version

1

manage version

2.7 Checks - check

By default, all applications will be selected.

1

python manage.py check

If no application is specified, all applications will be checked.

• tag

You can use tags to restrict the checks that are run to those in a specific category. For example, to run only the security and compatibility checks, run:
python manage.py check –tag security –tag compatibility

• list-tags

Lists all available tags

• deploy

The option activates some additional deployment-related checks.
python manage.py check –deploy –settings=production_settings

2.8 Flushing the database - flush

1

manage flush

• The database option can be used to specify the database to flush.
• no-initial-data
  Use –no-initial-data to avoid loading the initial_data fixture.

2.9 Reverse-generating models - inspectdb

1

manage inspectdb

2.10 Data models - validate

1

manage validate

2.11 Creating the cache table - createcachetable

1

manage createcachetable

• The database option can be used to specify the database in which to install the cache table

2.12 Generating SQL code from models - sql

1

manage sql

Prints out the SQL statements that create the app’s tables; it does not actually create them

2.13 Generating SQL code from models - sqlall

1

manage sqlall

Prints all the SQL statements for creating the app, including indexes

2.14 Database engine command-line client - dbshell

1

manage dbshell

• The database option can be used to specify the database on which to open the shell

2.15 Creating a superuser - createsuperuser

1

manage createsuperuser

2.16 Changing a user’s password - changepassword

1

manage changepassword username

• The database option specifies the database to look the user up in

2.17 Applying database changes - migrate

1

manage.py  makemigrations

Updates the migrations files

1

manage  migrate

Executes the commands in the database scripts, syncing the changes in the models layer to the database

2.18 Differences between the current and default settings - diffsettings

1

manage diffsettings

Shows the differences between the current settings file and the default settings file

2.19 Exporting the database - dumpdata

1

manage dumpdata

• format
  By default, dumpdata outputs its result in JSON format, but you can use the –format option to specify another format. The currently supported formats are listed in Serialization formats.
• indent
  By default, dumpdata outputs all data on a single line. This is not easy for humans to read, so you can use the –indent option to pretty-print the output with a number of indentation spaces.
• exclude
  Option to prevent specific applications or models (given as app_label.ModelName). If you specify a model name to dumpdata, the dumped output will be limited to that model rather than the whole application. You can also mix application names and model names.
• database
  Option can be used to specify the database to dump data from.
• natural-foreign
  Django will use the natural_key() model method to serialize any foreign key and many-to-many relationship to the objects of the type that defines the method.
• pks
  By default, dumpdata will output all records of the model, but you can use the –pks option to specify a comma-separated list of primary keys to filter by. This is only available when dumping a single model.
• output
  By default, the dumpdata command outputs all serialized data to standard output. Using the –output option allows you to specify the file the data is written to.

2.20 Importing data - loaddata

1

manage loaddata

• database
  Option can be used to specify the database to load the data into.
• ignorenonexistent
  Option can be used to ignore fields and models that may have been removed since the fixture was first generated.
• app
  Option can be used to specify a single application to look for fixtures in, rather than searching all applications.

2.21 Getting runtime help - help

• Running manage help shows usage information and the list of commands for each application
• Running manage help –commands shows a list containing all available commands
• Running manage help shows the description of a particular command and its list of available commands.

3. Running Management Commands from Code

django.core.management.call_command(name, *args, **options)

1
2
3
4
5
6
7

from django.core.management import call_command
call_command('flush', verbosity=0, interactive=False)
call_command('loaddata', 'test_data', verbosity=0)
call_command('dumpdata', '--natural-foreign')
call_command('dumpdata', exclude=['contenttypes', 'auth'])
with open('./command_output') as f:
    call_command('dumpdata', stdout=f)

4. Customizing manage Commands

During the development of a project, you will inevitably need some special handling operations. So the question arises: how do you avoid repeating these operations? That’s right — by customizing your own manage commands.

Django looks up commands through the find_commands and get_commands functions in django.core.management, that is, it looks for commands in django.core and in each app’s management/commands directory.

Now that you know the principle, you just need to create the following directories under your own app.

1
2
3

app/management/commands/__init__.py
app/management/commands/mycommands.py
app/managemen/__init__.py

1
2
3
4
5
6

# app/management/commands/mycommands.py
from django.core.management.base import BaseCommand, CommandError

class Command(BaseCommand):
     def handle(self, *args, **options):
         return 'hello, mycommands!'

1
2
3

# 执行mycommands命令
manage.py mycommands
hello, mycommands!

For more detailed examples, refer to the commands in django.core.management.commands.