mirror of
				https://github.com/django/django.git
				synced 2025-10-30 17:16:10 +00:00 
			
		
		
		
	
		
			
				
	
	
		
			2419 lines
		
	
	
		
			68 KiB
		
	
	
	
		
			Groff
		
	
	
	
	
	
			
		
		
	
	
			2419 lines
		
	
	
		
			68 KiB
		
	
	
	
		
			Groff
		
	
	
	
	
	
| .\" Man page generated from reStructuredText.
 | ||
| .
 | ||
| .TH "DJANGO-ADMIN" "1" "September 23, 2015" "1.9" "Django"
 | ||
| .SH NAME
 | ||
| django-admin \- Utility script for the Django Web framework
 | ||
| .
 | ||
| .nr rst2man-indent-level 0
 | ||
| .
 | ||
| .de1 rstReportMargin
 | ||
| \\$1 \\n[an-margin]
 | ||
| level \\n[rst2man-indent-level]
 | ||
| level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 | ||
| -
 | ||
| \\n[rst2man-indent0]
 | ||
| \\n[rst2man-indent1]
 | ||
| \\n[rst2man-indent2]
 | ||
| ..
 | ||
| .de1 INDENT
 | ||
| .\" .rstReportMargin pre:
 | ||
| . RS \\$1
 | ||
| . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
 | ||
| . nr rst2man-indent-level +1
 | ||
| .\" .rstReportMargin post:
 | ||
| ..
 | ||
| .de UNINDENT
 | ||
| . RE
 | ||
| .\" indent \\n[an-margin]
 | ||
| .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
 | ||
| .nr rst2man-indent-level -1
 | ||
| .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 | ||
| .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 | ||
| ..
 | ||
| .sp
 | ||
| \fBdjango\-admin\fP is Django\(aqs command\-line utility for administrative tasks.
 | ||
| This document outlines all it can do.
 | ||
| .sp
 | ||
| In addition, \fBmanage.py\fP is automatically created in each Django project.
 | ||
| \fBmanage.py\fP is a thin wrapper around \fBdjango\-admin\fP that takes care of
 | ||
| several things for you before delegating to \fBdjango\-admin\fP:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| It puts your project\(aqs package on \fBsys.path\fP\&.
 | ||
| .IP \(bu 2
 | ||
| It sets the \fBDJANGO_SETTINGS_MODULE\fP environment variable so that
 | ||
| it points to your project\(aqs \fBsettings.py\fP file.
 | ||
| .IP \(bu 2
 | ||
| It calls \fBdjango.setup()\fP to initialize various internals of Django.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fBdjango\-admin\fP script should be on your system path if you installed
 | ||
| Django via its \fBsetup.py\fP utility. If it\(aqs not on your path, you can find it
 | ||
| in \fBsite\-packages/django/bin\fP within your Python installation. Consider
 | ||
| symlinking it from some place on your path, such as \fB/usr/local/bin\fP\&.
 | ||
| .sp
 | ||
| For Windows users, who do not have symlinking functionality available, you can
 | ||
| copy \fBdjango\-admin.exe\fP to a location on your existing path or edit the
 | ||
| \fBPATH\fP settings (under \fBSettings \- Control Panel \- System \- Advanced \-
 | ||
| Environment...\fP) to point to its installed location.
 | ||
| .sp
 | ||
| Generally, when working on a single Django project, it\(aqs easier to use
 | ||
| \fBmanage.py\fP than \fBdjango\-admin\fP\&. If you need to switch between multiple
 | ||
| Django settings files, use \fBdjango\-admin\fP with
 | ||
| \fBDJANGO_SETTINGS_MODULE\fP or the \fI\%\-\-settings\fP command line
 | ||
| option.
 | ||
| .sp
 | ||
| The command\-line examples throughout this document use \fBdjango\-admin\fP to
 | ||
| be consistent, but any example can use \fBmanage.py\fP or \fBpython \-m django\fP
 | ||
| just as well.
 | ||
| .sp
 | ||
| \fBpython \-m django\fP was added.
 | ||
| 
 | ||
| .SH USAGE
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| $ django\-admin <command> [options]
 | ||
| $ manage.py <command> [options]
 | ||
| $ python \-m django <command> [options]
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| \fBcommand\fP should be one of the commands listed in this document.
 | ||
| \fBoptions\fP, which is optional, should be zero or more of the options available
 | ||
| for the given command.
 | ||
| .SS Getting runtime help
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin help
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Run \fBdjango\-admin help\fP to display usage information and a list of the
 | ||
| commands provided by each application.
 | ||
| .sp
 | ||
| Run \fBdjango\-admin help \-\-commands\fP to display a list of all available
 | ||
| commands.
 | ||
| .sp
 | ||
| Run \fBdjango\-admin help <command>\fP to display a description of the given
 | ||
| command and a list of its available options.
 | ||
| .SS App names
 | ||
| .sp
 | ||
| Many commands take a list of "app names." An "app name" is the basename of
 | ||
| the package containing your models. For example, if your \fBINSTALLED_APPS\fP
 | ||
| contains the string \fB\(aqmysite.blog\(aq\fP, the app name is \fBblog\fP\&.
 | ||
| .SS Determining the version
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin version
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Run \fBdjango\-admin version\fP to display the current Django version.
 | ||
| .sp
 | ||
| The output follows the schema described in \fI\%PEP 386\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| 1.4.dev17026
 | ||
| 1.4a1
 | ||
| 1.4
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS Displaying debug output
 | ||
| .sp
 | ||
| Use \fI\%\-\-verbosity\fP to specify the amount of notification and debug information
 | ||
| that \fBdjango\-admin\fP should print to the console. For more details, see the
 | ||
| documentation for the \fI\%\-\-verbosity\fP option.
 | ||
| .SH AVAILABLE COMMANDS
 | ||
| .SS check <appname appname ...>
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin check
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Uses the \fBsystem check framework\fP to inspect
 | ||
| the entire Django project for common problems.
 | ||
| .sp
 | ||
| The system check framework will confirm that there aren\(aqt any problems with
 | ||
| your installed models or your admin registrations. It will also provide warnings
 | ||
| of common compatibility problems introduced by upgrading Django to a new version.
 | ||
| Custom checks may be introduced by other libraries and applications.
 | ||
| .sp
 | ||
| By default, all apps will be checked. You can check a subset of apps by providing
 | ||
| a list of app labels as arguments:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| python manage.py check auth admin myapp
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| If you do not specify any app, all apps will be checked.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-tag <tagname>
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fBsystem check framework\fP performs many different
 | ||
| types of checks. These check types are categorized with tags. You can use these tags
 | ||
| to restrict the checks performed to just those in a particular category. For example,
 | ||
| to perform only security and compatibility checks, you would run:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| python manage.py check \-\-tag security \-\-tag compatibility
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-list\-tags
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| List all available tags.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-deploy
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-deploy\fP option activates some additional checks that are only relevant
 | ||
| in a deployment setting.
 | ||
| .sp
 | ||
| You can use this option in your local development environment, but since your
 | ||
| local development settings module may not have many of your production settings,
 | ||
| you will probably want to point the \fBcheck\fP command at a different settings
 | ||
| module, either by setting the \fBDJANGO_SETTINGS_MODULE\fP environment variable,
 | ||
| or by passing the \fB\-\-settings\fP option:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| python manage.py check \-\-deploy \-\-settings=production_settings
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Or you could run it directly on a production or staging deployment to verify
 | ||
| that the correct settings are in use (omitting \fB\-\-settings\fP). You could even
 | ||
| make it part of your integration test suite.
 | ||
| .SS compilemessages
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin compilemessages
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Compiles .po files created by \fI\%makemessages\fP to .mo files for use with
 | ||
| the builtin gettext support. See \fB/topics/i18n/index\fP\&.
 | ||
| .sp
 | ||
| Use the \fI\%\-\-locale\fP option (or its shorter version \fB\-l\fP) to
 | ||
| specify the locale(s) to process. If not provided, all locales are processed.
 | ||
| .sp
 | ||
| Use the \fI\%\-\-exclude\fP option (or its shorter version \fB\-x\fP) to
 | ||
| specify the locale(s) to exclude from processing. If not provided, no locales
 | ||
| are excluded.
 | ||
| .sp
 | ||
| You can pass \fB\-\-use\-fuzzy\fP option (or \fB\-f\fP) to include fuzzy translations
 | ||
| into compiled files.
 | ||
| .sp
 | ||
| \fBcompilemessages\fP now matches the operation of \fI\%makemessages\fP,
 | ||
| scanning the project tree for \fB\&.po\fP files to compile.
 | ||
| 
 | ||
| .sp
 | ||
| Added \fB\-\-exclude\fP and \fB\-\-use\-fuzzy\fP options.
 | ||
| 
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin compilemessages \-\-locale=pt_BR
 | ||
| django\-admin compilemessages \-\-locale=pt_BR \-\-locale=fr \-f
 | ||
| django\-admin compilemessages \-l pt_BR
 | ||
| django\-admin compilemessages \-l pt_BR \-l fr \-\-use\-fuzzy
 | ||
| django\-admin compilemessages \-\-exclude=pt_BR
 | ||
| django\-admin compilemessages \-\-exclude=pt_BR \-\-exclude=fr
 | ||
| django\-admin compilemessages \-x pt_BR
 | ||
| django\-admin compilemessages \-x pt_BR \-x fr
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS createcachetable
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin createcachetable
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Creates the cache tables for use with the database cache backend using the
 | ||
| information from your settings file. See \fB/topics/cache\fP for more
 | ||
| information.
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option can be used to specify the database
 | ||
| onto which the cache table will be installed, but since this information is
 | ||
| pulled from your settings by default, it\(aqs typically not needed.
 | ||
| .sp
 | ||
| The \fI\%\-\-dry\-run\fP option will print the SQL that would be run without
 | ||
| actually running it, so you can customize it or use the migrations framework.
 | ||
| .sp
 | ||
| The \fB\-\-dry\-run\fP option was added.
 | ||
| 
 | ||
| .SS dbshell
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin dbshell
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Runs the command\-line client for the database engine specified in your
 | ||
| \fBENGINE\fP setting, with the connection parameters specified in your
 | ||
| \fBUSER\fP, \fBPASSWORD\fP, etc., settings.
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| For PostgreSQL, this runs the \fBpsql\fP command\-line client.
 | ||
| .IP \(bu 2
 | ||
| For MySQL, this runs the \fBmysql\fP command\-line client.
 | ||
| .IP \(bu 2
 | ||
| For SQLite, this runs the \fBsqlite3\fP command\-line client.
 | ||
| .IP \(bu 2
 | ||
| For Oracle, this runs the \fBsqlplus\fP command\-line client.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| This command assumes the programs are on your \fBPATH\fP so that a simple call to
 | ||
| the program name (\fBpsql\fP, \fBmysql\fP, \fBsqlite3\fP, \fBsqlplus\fP) will find the
 | ||
| program in the right place. There\(aqs no way to specify the location of the
 | ||
| program manually.
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option can be used to specify the database
 | ||
| onto which to open a shell.
 | ||
| .SS diffsettings
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin diffsettings
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Displays differences between the current settings file and Django\(aqs default
 | ||
| settings.
 | ||
| .sp
 | ||
| Settings that don\(aqt appear in the defaults are followed by \fB"###"\fP\&. For
 | ||
| example, the default settings don\(aqt define \fBROOT_URLCONF\fP, so
 | ||
| \fBROOT_URLCONF\fP is followed by \fB"###"\fP in the output of
 | ||
| \fBdiffsettings\fP\&.
 | ||
| .sp
 | ||
| The \fI\%\-\-all\fP option may be provided to display all settings, even
 | ||
| if they have Django\(aqs default value. Such settings are prefixed by \fB"###"\fP\&.
 | ||
| .SS dumpdata <app_label app_label app_label.Model ...>
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin dumpdata
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Outputs to standard output all data in the database associated with the named
 | ||
| application(s).
 | ||
| .sp
 | ||
| If no application name is provided, all installed applications will be dumped.
 | ||
| .sp
 | ||
| The output of \fBdumpdata\fP can be used as input for \fI\%loaddata\fP\&.
 | ||
| .sp
 | ||
| Note that \fBdumpdata\fP uses the default manager on the model for selecting the
 | ||
| records to dump. If you\(aqre using a custom manager as
 | ||
| the default manager and it filters some of the available records, not all of the
 | ||
| objects will be dumped.
 | ||
| .sp
 | ||
| The \fI\%\-\-all\fP option may be provided to specify that
 | ||
| \fBdumpdata\fP should use Django\(aqs base manager, dumping records which
 | ||
| might otherwise be filtered or modified by a custom manager.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-format <fmt>
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| By default, \fBdumpdata\fP will format its output in JSON, but you can use the
 | ||
| \fB\-\-format\fP option to specify another format. Currently supported formats
 | ||
| are listed in serialization\-formats\&.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-indent <num>
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| By default, \fBdumpdata\fP will output all data on a single line. This isn\(aqt
 | ||
| easy for humans to read, so you can use the \fB\-\-indent\fP option to
 | ||
| pretty\-print the output with a number of indentation spaces.
 | ||
| .sp
 | ||
| The \fI\%\-\-exclude\fP option may be provided to prevent specific
 | ||
| applications or models (specified as in the form of \fBapp_label.ModelName\fP)
 | ||
| from being dumped. If you specify a model name to \fBdumpdata\fP, the dumped
 | ||
| output will be restricted to that model, rather than the entire application.
 | ||
| You can also mix application names and model names.
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option can be used to specify the database
 | ||
| from which data will be dumped.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-natural\-foreign
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| When this option is specified, Django will use the \fBnatural_key()\fP model
 | ||
| method to serialize any foreign key and many\-to\-many relationship to objects of
 | ||
| the type that defines the method. If you are dumping \fBcontrib.auth\fP
 | ||
| \fBPermission\fP objects or \fBcontrib.contenttypes\fP \fBContentType\fP objects, you
 | ||
| should probably be using this flag. See the natural keys documentation for more details on this
 | ||
| and the next option.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-natural\-primary
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| When this option is specified, Django will not provide the primary key in the
 | ||
| serialized data of this object since it can be calculated during
 | ||
| deserialization.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-pks
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| By default, \fBdumpdata\fP will output all the records of the model, but
 | ||
| you can use the \fB\-\-pks\fP option to specify a comma separated list of
 | ||
| primary keys on which to filter.  This is only available when dumping
 | ||
| one model.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-output
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| By default \fBdumpdata\fP will output all the serialized data to standard output.
 | ||
| This option allows you to specify the file to which the data is to be written.
 | ||
| When this option is set and the verbosity is greater than 0 (the default), a
 | ||
| progress bar is shown in the terminal.
 | ||
| .sp
 | ||
| The progress bar in the terminal was added.
 | ||
| 
 | ||
| .SS flush
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin flush
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Removes all data from the database and re\-executes any post\-synchronization
 | ||
| handlers. The table of which migrations have been applied is not cleared.
 | ||
| .sp
 | ||
| If you would rather start from an empty database and re\-run all migrations, you
 | ||
| should drop and recreate the database and then run \fI\%migrate\fP instead.
 | ||
| .sp
 | ||
| The \fI\%\-\-noinput\fP option may be provided to suppress all user
 | ||
| prompts.
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option may be used to specify the database
 | ||
| to flush.
 | ||
| .SS inspectdb
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin inspectdb
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Introspects the database tables in the database pointed\-to by the
 | ||
| \fBNAME\fP setting and outputs a Django model module (a \fBmodels.py\fP
 | ||
| file) to standard output.
 | ||
| .sp
 | ||
| Use this if you have a legacy database with which you\(aqd like to use Django.
 | ||
| The script will inspect the database and create a model for each table within
 | ||
| it.
 | ||
| .sp
 | ||
| As you might expect, the created models will have an attribute for every field
 | ||
| in the table. Note that \fBinspectdb\fP has a few special cases in its field\-name
 | ||
| output:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| If \fBinspectdb\fP cannot map a column\(aqs type to a model field type, it\(aqll
 | ||
| use \fBTextField\fP and will insert the Python comment
 | ||
| \fB\(aqThis field type is a guess.\(aq\fP next to the field in the generated
 | ||
| model.
 | ||
| .IP \(bu 2
 | ||
| If the database column name is a Python reserved word (such as
 | ||
| \fB\(aqpass\(aq\fP, \fB\(aqclass\(aq\fP or \fB\(aqfor\(aq\fP), \fBinspectdb\fP will append
 | ||
| \fB\(aq_field\(aq\fP to the attribute name. For example, if a table has a column
 | ||
| \fB\(aqfor\(aq\fP, the generated model will have a field \fB\(aqfor_field\(aq\fP, with
 | ||
| the \fBdb_column\fP attribute set to \fB\(aqfor\(aq\fP\&. \fBinspectdb\fP will insert
 | ||
| the Python comment
 | ||
| \fB\(aqField renamed because it was a Python reserved word.\(aq\fP next to the
 | ||
| field.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| This feature is meant as a shortcut, not as definitive model generation. After
 | ||
| you run it, you\(aqll want to look over the generated models yourself to make
 | ||
| customizations. In particular, you\(aqll need to rearrange models\(aq order, so that
 | ||
| models that refer to other models are ordered properly.
 | ||
| .sp
 | ||
| Primary keys are automatically introspected for PostgreSQL, MySQL and
 | ||
| SQLite, in which case Django puts in the \fBprimary_key=True\fP where
 | ||
| needed.
 | ||
| .sp
 | ||
| \fBinspectdb\fP works with PostgreSQL, MySQL and SQLite. Foreign\-key detection
 | ||
| only works in PostgreSQL and with certain types of MySQL tables.
 | ||
| .sp
 | ||
| Django doesn\(aqt create database defaults when a
 | ||
| \fBdefault\fP is specified on a model field.
 | ||
| Similarly, database defaults aren\(aqt translated to model field defaults or
 | ||
| detected in any fashion by \fBinspectdb\fP\&.
 | ||
| .sp
 | ||
| By default, \fBinspectdb\fP creates unmanaged models. That is, \fBmanaged = False\fP
 | ||
| in the model\(aqs \fBMeta\fP class tells Django not to manage each table\(aqs creation,
 | ||
| modification, and deletion. If you do want to allow Django to manage the
 | ||
| table\(aqs lifecycle, you\(aqll need to change the
 | ||
| \fBmanaged\fP option to \fBTrue\fP (or simply remove
 | ||
| it because \fBTrue\fP is its default value).
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option may be used to specify the
 | ||
| database to introspect.
 | ||
| .SS loaddata <fixture fixture ...>
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin loaddata
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Searches for and loads the contents of the named fixture into the database.
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option can be used to specify the database
 | ||
| onto which the data will be loaded.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-ignorenonexistent
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fI\%\-\-ignorenonexistent\fP option can be used to ignore fields and
 | ||
| models that may have been removed since the fixture was originally generated.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-app
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fI\%\-\-app\fP option can be used to specify a single app to look
 | ||
| for fixtures in rather than looking through all apps.
 | ||
| .sp
 | ||
| \fB\-\-ignorenonexistent\fP also ignores non\-existent models.
 | ||
| 
 | ||
| .SS What\(aqs a "fixture"?
 | ||
| .sp
 | ||
| A \fIfixture\fP is a collection of files that contain the serialized contents of
 | ||
| the database. Each fixture has a unique name, and the files that comprise the
 | ||
| fixture can be distributed over multiple directories, in multiple applications.
 | ||
| .sp
 | ||
| Django will search in three locations for fixtures:
 | ||
| .INDENT 0.0
 | ||
| .IP 1. 3
 | ||
| In the \fBfixtures\fP directory of every installed application
 | ||
| .IP 2. 3
 | ||
| In any directory named in the \fBFIXTURE_DIRS\fP setting
 | ||
| .IP 3. 3
 | ||
| In the literal path named by the fixture
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Django will load any and all fixtures it finds in these locations that match
 | ||
| the provided fixture names.
 | ||
| .sp
 | ||
| If the named fixture has a file extension, only fixtures of that type
 | ||
| will be loaded. For example:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin loaddata mydata.json
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| would only load JSON fixtures called \fBmydata\fP\&. The fixture extension
 | ||
| must correspond to the registered name of a
 | ||
| serializer (e.g., \fBjson\fP or \fBxml\fP).
 | ||
| .sp
 | ||
| If you omit the extensions, Django will search all available fixture types
 | ||
| for a matching fixture. For example:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin loaddata mydata
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| would look for any fixture of any fixture type called \fBmydata\fP\&. If a fixture
 | ||
| directory contained \fBmydata.json\fP, that fixture would be loaded
 | ||
| as a JSON fixture.
 | ||
| .sp
 | ||
| The fixtures that are named can include directory components. These
 | ||
| directories will be included in the search path. For example:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin loaddata foo/bar/mydata.json
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| would search \fB<app_label>/fixtures/foo/bar/mydata.json\fP for each installed
 | ||
| application,  \fB<dirname>/foo/bar/mydata.json\fP for each directory in
 | ||
| \fBFIXTURE_DIRS\fP, and the literal path \fBfoo/bar/mydata.json\fP\&.
 | ||
| .sp
 | ||
| When fixture files are processed, the data is saved to the database as is.
 | ||
| Model defined \fBsave()\fP methods are not called, and
 | ||
| any \fBpre_save\fP or
 | ||
| \fBpost_save\fP signals will be called with
 | ||
| \fBraw=True\fP since the instance only contains attributes that are local to the
 | ||
| model. You may, for example, want to disable handlers that access
 | ||
| related fields that aren\(aqt present during fixture loading and would otherwise
 | ||
| raise an exception:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| from django.db.models.signals import post_save
 | ||
| from .models import MyModel
 | ||
| 
 | ||
| def my_handler(**kwargs):
 | ||
|     # disable the handler during fixture loading
 | ||
|     if kwargs[\(aqraw\(aq]:
 | ||
|         return
 | ||
|     ...
 | ||
| 
 | ||
| post_save.connect(my_handler, sender=MyModel)
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| You could also write a simple decorator to encapsulate this logic:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| from functools import wraps
 | ||
| 
 | ||
| def disable_for_loaddata(signal_handler):
 | ||
|     """
 | ||
|     Decorator that turns off signal handlers when loading fixture data.
 | ||
|     """
 | ||
|     @wraps(signal_handler)
 | ||
|     def wrapper(*args, **kwargs):
 | ||
|         if kwargs[\(aqraw\(aq]:
 | ||
|             return
 | ||
|         signal_handler(*args, **kwargs)
 | ||
|     return wrapper
 | ||
| 
 | ||
| @disable_for_loaddata
 | ||
| def my_handler(**kwargs):
 | ||
|     ...
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Just be aware that this logic will disable the signals whenever fixtures are
 | ||
| deserialized, not just during \fBloaddata\fP\&.
 | ||
| .sp
 | ||
| Note that the order in which fixture files are processed is undefined. However,
 | ||
| all fixture data is installed as a single transaction, so data in
 | ||
| one fixture can reference data in another fixture. If the database backend
 | ||
| supports row\-level constraints, these constraints will be checked at the
 | ||
| end of the transaction.
 | ||
| .sp
 | ||
| The \fI\%dumpdata\fP command can be used to generate input for \fBloaddata\fP\&.
 | ||
| .SS Compressed fixtures
 | ||
| .sp
 | ||
| Fixtures may be compressed in \fBzip\fP, \fBgz\fP, or \fBbz2\fP format. For example:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin loaddata mydata.json
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| would look for any of \fBmydata.json\fP, \fBmydata.json.zip\fP,
 | ||
| \fBmydata.json.gz\fP, or \fBmydata.json.bz2\fP\&. The first file contained within a
 | ||
| zip\-compressed archive is used.
 | ||
| .sp
 | ||
| Note that if two fixtures with the same name but different
 | ||
| fixture type are discovered (for example, if \fBmydata.json\fP and
 | ||
| \fBmydata.xml.gz\fP were found in the same fixture directory), fixture
 | ||
| installation will be aborted, and any data installed in the call to
 | ||
| \fBloaddata\fP will be removed from the database.
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .IP "MySQL with MyISAM and fixtures"
 | ||
| .sp
 | ||
| The MyISAM storage engine of MySQL doesn\(aqt support transactions or
 | ||
| constraints, so if you use MyISAM, you won\(aqt get validation of fixture
 | ||
| data, or a rollback if multiple transaction files are found.
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS Database\-specific fixtures
 | ||
| .sp
 | ||
| If you\(aqre in a multi\-database setup, you might have fixture data that
 | ||
| you want to load onto one database, but not onto another. In this
 | ||
| situation, you can add a database identifier into the names of your fixtures.
 | ||
| .sp
 | ||
| For example, if your \fBDATABASES\fP setting has a \(aqmaster\(aq database
 | ||
| defined, name the fixture \fBmydata.master.json\fP or
 | ||
| \fBmydata.master.json.gz\fP and the fixture will only be loaded when you
 | ||
| specify you want to load data into the \fBmaster\fP database.
 | ||
| .SS makemessages
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin makemessages
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Runs over the entire source tree of the current directory and pulls out all
 | ||
| strings marked for translation. It creates (or updates) a message file in the
 | ||
| conf/locale (in the Django tree) or locale (for project and application)
 | ||
| directory. After making changes to the messages files you need to compile them
 | ||
| with \fI\%compilemessages\fP for use with the builtin gettext support. See
 | ||
| the i18n documentation for details.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-all
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-all\fP or \fB\-a\fP option to update the message files for all
 | ||
| available languages.
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin makemessages \-\-all
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-extension
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-extension\fP or \fB\-e\fP option to specify a list of file extensions
 | ||
| to examine (default: ".html", ".txt").
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin makemessages \-\-locale=de \-\-extension xhtml
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Separate multiple extensions with commas or use \-e or \-\-extension multiple times:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin makemessages \-\-locale=de \-\-extension=html,txt \-\-extension xml
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fI\%\-\-locale\fP option (or its shorter version \fB\-l\fP) to
 | ||
| specify the locale(s) to process.
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| Use the \fI\%\-\-exclude\fP option (or its shorter version \fB\-x\fP) to
 | ||
| specify the locale(s) to exclude from processing. If not provided, no locales
 | ||
| are excluded.
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin makemessages \-\-locale=pt_BR
 | ||
| django\-admin makemessages \-\-locale=pt_BR \-\-locale=fr
 | ||
| django\-admin makemessages \-l pt_BR
 | ||
| django\-admin makemessages \-l pt_BR \-l fr
 | ||
| django\-admin makemessages \-\-exclude=pt_BR
 | ||
| django\-admin makemessages \-\-exclude=pt_BR \-\-exclude=fr
 | ||
| django\-admin makemessages \-x pt_BR
 | ||
| django\-admin makemessages \-x pt_BR \-x fr
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-domain
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-domain\fP or \fB\-d\fP option to change the domain of the messages files.
 | ||
| Currently supported:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| \fBdjango\fP for all \fB*.py\fP, \fB*.html\fP and \fB*.txt\fP files (default)
 | ||
| .IP \(bu 2
 | ||
| \fBdjangojs\fP for \fB*.js\fP files
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-symlinks
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-symlinks\fP or \fB\-s\fP option to follow symlinks to directories when
 | ||
| looking for new translation strings.
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin makemessages \-\-locale=de \-\-symlinks
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-ignore
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-ignore\fP or \fB\-i\fP option to ignore files or directories matching
 | ||
| the given \fI\%glob\fP\-style pattern. Use multiple times to ignore more.
 | ||
| .sp
 | ||
| These patterns are used by default: \fB\(aqCVS\(aq\fP, \fB\(aq.*\(aq\fP, \fB\(aq*~\(aq\fP, \fB\(aq*.pyc\(aq\fP
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin makemessages \-\-locale=en_US \-\-ignore=apps/* \-\-ignore=secret/*.html
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-no\-default\-ignore
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-no\-default\-ignore\fP option to disable the default values of
 | ||
| \fI\%\-\-ignore\fP\&.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-no\-wrap
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-no\-wrap\fP option to disable breaking long message lines into
 | ||
| several lines in language files.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-no\-location
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-no\-location\fP option to suppress writing \(aq\fB#: filename:line\fP’
 | ||
| comment lines in language files. Note that using this option makes it harder
 | ||
| for technically skilled translators to understand each message\(aqs context.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-keep\-pot
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-keep\-pot\fP option to prevent Django from deleting the temporary
 | ||
| .pot files it generates before creating the .po file. This is useful for
 | ||
| debugging errors which may prevent the final language files from being created.
 | ||
| .sp
 | ||
| \fBSEE ALSO:\fP
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| See customizing\-makemessages for instructions on how to customize
 | ||
| the keywords that \fI\%makemessages\fP passes to \fBxgettext\fP\&.
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS makemigrations [<app_label>]
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin makemigrations
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Creates new migrations based on the changes detected to your models.
 | ||
| Migrations, their relationship with apps and more are covered in depth in
 | ||
| \fBthe migrations documentation\fP\&.
 | ||
| .sp
 | ||
| Providing one or more app names as arguments will limit the migrations created
 | ||
| to the app(s) specified and any dependencies needed (the table at the other end
 | ||
| of a \fBForeignKey\fP, for example).
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-noinput\fP option may be provided to suppress all user prompts. If a suppressed
 | ||
| prompt cannot be resolved automatically, the command will exit with error code 3.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-empty
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-empty\fP option will cause \fBmakemigrations\fP 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.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-dry\-run
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-dry\-run\fP option shows what migrations would be made without
 | ||
| actually writing any migrations files to disk. Using this option along with
 | ||
| \fB\-\-verbosity 3\fP will also show the complete migrations files that would be
 | ||
| written.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-merge
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-merge\fP option enables fixing of migration conflicts.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-name, \-n
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-name\fP option allows you to give the migration(s) a custom name instead
 | ||
| of a generated one.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-exit, \-e
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-exit\fP option will cause \fBmakemigrations\fP to exit with error code 1
 | ||
| when no migrations are created (or would have been created, if combined with
 | ||
| \fB\-\-dry\-run\fP).
 | ||
| .SS migrate [<app_label> [<migrationname>]]
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin migrate
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Synchronizes the database state with the current set of models and migrations.
 | ||
| Migrations, their relationship with apps and more are covered in depth in
 | ||
| \fBthe migrations documentation\fP\&.
 | ||
| .sp
 | ||
| The behavior of this command changes depending on the arguments provided:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| No arguments: All apps have all of their migrations run.
 | ||
| .IP \(bu 2
 | ||
| \fB<app_label>\fP: The specified app has its migrations run, up to the most
 | ||
| recent migration. This may involve running other apps\(aq migrations too, due
 | ||
| to dependencies.
 | ||
| .IP \(bu 2
 | ||
| \fB<app_label> <migrationname>\fP: Brings the database schema to a state where
 | ||
| the named migration is applied, but no later migrations in the same app are
 | ||
| applied. This may involve unapplying migrations if you have previously
 | ||
| migrated past the named migration. Use the name \fBzero\fP to unapply all
 | ||
| migrations for an app.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option can be used to specify the database to
 | ||
| migrate.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-fake
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-fake\fP option tells Django to mark the migrations as having been
 | ||
| applied or unapplied, but without actually running the SQL to change your
 | ||
| database schema.
 | ||
| .sp
 | ||
| This is intended for advanced users to manipulate the
 | ||
| current migration state directly if they\(aqre manually applying changes;
 | ||
| be warned that using \fB\-\-fake\fP runs the risk of putting the migration state
 | ||
| table into a state where manual recovery will be needed to make migrations
 | ||
| run correctly.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-fake\-initial
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-fake\-initial\fP option can be used to allow Django to skip an app\(aqs
 | ||
| initial migration if all database tables with the names of all models created
 | ||
| by all \fBCreateModel\fP operations in that
 | ||
| migration already exist. This option is intended for use when first running
 | ||
| migrations against a database that preexisted the use of migrations. This
 | ||
| option does not, however, check for matching database schema beyond matching
 | ||
| table names and so is only safe to use if you are confident that your existing
 | ||
| schema matches what is recorded in your initial migration.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-run\-syncdb
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-run\-syncdb\fP option allows creating tables for apps without migrations.
 | ||
| While this isn\(aqt recommended, the migrations framework is sometimes too slow
 | ||
| on large projects with hundreds of models.
 | ||
| .sp
 | ||
| Deprecated since version 1.8: The \fB\-\-list\fP option has been moved to the \fI\%showmigrations\fP
 | ||
| command.
 | ||
| 
 | ||
| .SS runserver [port or address:port]
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin runserver
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Starts a lightweight development Web server on the local machine. By default,
 | ||
| the server runs on port 8000 on the IP address \fB127.0.0.1\fP\&. You can pass in an
 | ||
| IP address and port number explicitly.
 | ||
| .sp
 | ||
| If you run this script as a user with normal privileges (recommended), you
 | ||
| might not have access to start a port on a low port number. Low port numbers
 | ||
| are reserved for the superuser (root).
 | ||
| .sp
 | ||
| This server uses the WSGI application object specified by the
 | ||
| \fBWSGI_APPLICATION\fP setting.
 | ||
| .sp
 | ||
| DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
 | ||
| security audits or performance tests. (And that\(aqs how it\(aqs gonna stay. We\(aqre in
 | ||
| the business of making Web frameworks, not Web servers, so improving this
 | ||
| server to be able to handle a production environment is outside the scope of
 | ||
| Django.)
 | ||
| .sp
 | ||
| The development server automatically reloads Python code for each request, as
 | ||
| needed. You don\(aqt need to restart the server for code changes to take effect.
 | ||
| However, some actions like adding files don\(aqt trigger a restart, so you\(aqll
 | ||
| have to restart the server in these cases.
 | ||
| .sp
 | ||
| If you are using Linux and install \fI\%pyinotify\fP, kernel signals will be used to
 | ||
| autoreload the server (rather than polling file modification timestamps each
 | ||
| second). This offers better scaling to large projects, reduction in response
 | ||
| time to code modification, more robust change detection, and battery usage
 | ||
| reduction.
 | ||
| .sp
 | ||
| When you start the server, and each time you change Python code while the
 | ||
| server is running, the system check framework will check your entire Django
 | ||
| project for some common errors (see the \fI\%check\fP command). If any
 | ||
| errors are found, they will be printed to standard output.
 | ||
| .sp
 | ||
| You can run as many concurrent servers as you want, as long as they\(aqre on
 | ||
| separate ports. Just execute \fBdjango\-admin runserver\fP more than once.
 | ||
| .sp
 | ||
| Note that the default IP address, \fB127.0.0.1\fP, is not accessible from other
 | ||
| machines on your network. To make your development server viewable to other
 | ||
| machines on the network, use its own IP address (e.g. \fB192.168.2.1\fP) or
 | ||
| \fB0.0.0.0\fP or \fB::\fP (with IPv6 enabled).
 | ||
| .sp
 | ||
| You can provide an IPv6 address surrounded by brackets
 | ||
| (e.g. \fB[200a::1]:8000\fP). This will automatically enable IPv6 support.
 | ||
| .sp
 | ||
| A hostname containing ASCII\-only characters can also be used.
 | ||
| .sp
 | ||
| If the \fBstaticfiles\fP contrib app is enabled
 | ||
| (default in new projects) the \fI\%runserver\fP command will be overridden
 | ||
| with its own runserver command.
 | ||
| .sp
 | ||
| If \fI\%migrate\fP was not previously executed, the table that stores the
 | ||
| history of migrations is created at first run of \fBrunserver\fP\&.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-noreload
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-noreload\fP option to disable the use of the auto\-reloader. This
 | ||
| means any Python code changes you make while the server is running will \fInot\fP
 | ||
| take effect if the particular Python modules have already been loaded into
 | ||
| memory.
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver \-\-noreload
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-nothreading
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The development server is multithreaded by default. Use the \fB\-\-nothreading\fP
 | ||
| option to disable the use of threading in the development server.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-ipv6, \-6
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-ipv6\fP (or shorter \fB\-6\fP) option to tell Django to use IPv6 for
 | ||
| the development server. This changes the default IP address from
 | ||
| \fB127.0.0.1\fP to \fB::1\fP\&.
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver \-\-ipv6
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS Examples of using different ports and addresses
 | ||
| .sp
 | ||
| Port 8000 on IP address \fB127.0.0.1\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Port 8000 on IP address \fB1.2.3.4\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver 1.2.3.4:8000
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Port 7000 on IP address \fB127.0.0.1\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver 7000
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Port 7000 on IP address \fB1.2.3.4\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver 1.2.3.4:7000
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Port 8000 on IPv6 address \fB::1\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver \-6
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Port 7000 on IPv6 address \fB::1\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver \-6 7000
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Port 7000 on IPv6 address \fB2001:0db8:1234:5678::9\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver [2001:0db8:1234:5678::9]:7000
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Port 8000 on IPv4 address of host \fBlocalhost\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver localhost:8000
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Port 8000 on IPv6 address of host \fBlocalhost\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin runserver \-6 localhost:8000
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS Serving static files with the development server
 | ||
| .sp
 | ||
| By default, the development server doesn\(aqt serve any static files for your site
 | ||
| (such as CSS files, images, things under \fBMEDIA_URL\fP and so forth). If
 | ||
| you want to configure Django to serve static media, read
 | ||
| \fB/howto/static\-files/index\fP\&.
 | ||
| .SS sendtestemail
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin sendtestemail
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| Sends a test email (to confirm email sending through Django is working) to the
 | ||
| recipient(s) specified. For example:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin sendtestemail foo@example.com bar@example.com
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-managers
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-managers\fP option to mail the email addresses specified in
 | ||
| \fBMANAGERS\fP using \fBmail_managers()\fP\&.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-admins
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-admins\fP option to mail the email addresses specified in
 | ||
| \fBADMINS\fP using \fBmail_admins()\fP\&.
 | ||
| .sp
 | ||
| Note that you may use any combination of these options together.
 | ||
| .SS shell
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin shell
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Starts the Python interactive interpreter.
 | ||
| .sp
 | ||
| Django will use \fI\%IPython\fP or \fI\%bpython\fP if either is installed. If you have a
 | ||
| rich shell installed but want to force use of the "plain" Python interpreter,
 | ||
| use the \fB\-\-plain\fP option, like so:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin shell \-\-plain
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| If you would like to specify either IPython or bpython as your interpreter if
 | ||
| you have both installed you can specify an alternative interpreter interface
 | ||
| with the \fB\-i\fP or \fB\-\-interface\fP options like so:
 | ||
| .sp
 | ||
| IPython:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin shell \-i ipython
 | ||
| django\-admin shell \-\-interface ipython
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| bpython:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin shell \-i bpython
 | ||
| django\-admin shell \-\-interface bpython
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| When the "plain" Python interactive interpreter starts (be it because
 | ||
| \fB\-\-plain\fP was specified or because no other interactive interface is
 | ||
| available) it reads the script pointed to by the \fI\%PYTHONSTARTUP\fP
 | ||
| environment variable and the \fB~/.pythonrc.py\fP script. If you don\(aqt wish this
 | ||
| behavior you can use the \fB\-\-no\-startup\fP option. e.g.:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin shell \-\-plain \-\-no\-startup
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS showmigrations [<app_label> [<app_label>]]
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin showmigrations
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| Shows all migrations in a project.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-list, \-l
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-list\fP option lists all of the apps Django knows about, the
 | ||
| migrations available for each app, and whether or not each migration is
 | ||
| applied (marked by an \fB[X]\fP next to the migration name).
 | ||
| .sp
 | ||
| Apps without migrations are also listed, but have \fB(no migrations)\fP printed
 | ||
| under them.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-plan, \-p
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-plan\fP option shows the migration plan Django will follow to apply
 | ||
| migrations. Any supplied app labels are ignored because the plan might go
 | ||
| beyond those apps. Same as \fB\-\-list\fP, applied migrations are marked by an
 | ||
| \fB[X]\fP\&. For a verbosity of 2 and above, all dependencies of a migration will
 | ||
| also be shown.
 | ||
| .SS sqlflush
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin sqlflush
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Prints the SQL statements that would be executed for the \fI\%flush\fP
 | ||
| command.
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option can be used to specify the database for
 | ||
| which to print the SQL.
 | ||
| .SS sqlmigrate <app_label> <migrationname>
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin sqlmigrate
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Prints the SQL for the named migration. This requires an active database
 | ||
| connection, which it will use to resolve constraint names; this means you must
 | ||
| generate the SQL against a copy of the database you wish to later apply it on.
 | ||
| .sp
 | ||
| Note that \fBsqlmigrate\fP doesn\(aqt colorize its output.
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option can be used to specify the database for
 | ||
| which to generate the SQL.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-backwards
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| By default, the SQL created is for running the migration in the forwards
 | ||
| direction. Pass \fB\-\-backwards\fP to generate the SQL for
 | ||
| unapplying the migration instead.
 | ||
| .sp
 | ||
| To increase the readability of the overall SQL output the SQL code
 | ||
| generated for each migration operation is preceded by the operation\(aqs
 | ||
| description.
 | ||
| 
 | ||
| .SS sqlsequencereset <app_label app_label ...>
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin sqlsequencereset
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Prints the SQL statements for resetting sequences for the given app name(s).
 | ||
| .sp
 | ||
| Sequences are indexes used by some database engines to track the next available
 | ||
| number for automatically incremented fields.
 | ||
| .sp
 | ||
| Use this command to generate SQL which will fix cases where a sequence is out
 | ||
| of sync with its automatically incremented field data.
 | ||
| .sp
 | ||
| The \fI\%\-\-database\fP option can be used to specify the database for
 | ||
| which to print the SQL.
 | ||
| .SS squashmigrations <app_label> [<start_migration_name>] <migration_name>
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin squashmigrations
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Squashes the migrations for \fBapp_label\fP up to and including \fBmigration_name\fP
 | ||
| down into fewer migrations, if possible. The resulting squashed migrations
 | ||
| can live alongside the unsquashed ones safely. For more information,
 | ||
| please read migration\-squashing\&.
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| When \fBstart_migration_name\fP is given, Django will only include migrations
 | ||
| starting from and including this migration. This helps to mitigate the
 | ||
| squashing limitation of \fBRunPython\fP and
 | ||
| \fBdjango.db.migrations.operations.RunSQL\fP migration operations.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-no\-optimize
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| By default, Django will try to optimize the operations in your migrations
 | ||
| to reduce the size of the resulting file. Pass \fB\-\-no\-optimize\fP if this
 | ||
| process is failing for you or creating incorrect migrations, though please
 | ||
| also file a Django bug report about the behavior, as optimization is meant
 | ||
| to be safe.
 | ||
| .SS startapp <app_label> [destination]
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin startapp
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Creates a Django app directory structure for the given app name in the current
 | ||
| directory or the given destination.
 | ||
| .sp
 | ||
| By default the directory created contains a \fBmodels.py\fP file and other app
 | ||
| template files. (See the \fI\%source\fP for more details.) If only the app
 | ||
| name is given, the app directory will be created in the current working
 | ||
| directory.
 | ||
| .sp
 | ||
| If the optional destination is provided, Django will use that existing
 | ||
| directory rather than creating a new one. You can use \(aq.\(aq to denote the current
 | ||
| working directory.
 | ||
| .sp
 | ||
| For example:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin startapp myapp /Users/jezdez/Code/myapp
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-template
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| With the \fB\-\-template\fP option, you can use a custom app template by providing
 | ||
| either the path to a directory with the app template file, or a path to a
 | ||
| compressed file (\fB\&.tar.gz\fP, \fB\&.tar.bz2\fP, \fB\&.tgz\fP, \fB\&.tbz\fP, \fB\&.zip\fP)
 | ||
| containing the app template files.
 | ||
| .sp
 | ||
| For example, this would look for an app template in the given directory when
 | ||
| creating the \fBmyapp\fP app:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin startapp \-\-template=/Users/jezdez/Code/my_app_template myapp
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Django will also accept URLs (\fBhttp\fP, \fBhttps\fP, \fBftp\fP) to compressed
 | ||
| archives with the app template files, downloading and extracting them on the
 | ||
| fly.
 | ||
| .sp
 | ||
| For example, taking advantage of GitHub\(aqs feature to expose repositories as
 | ||
| zip files, you can use a URL like:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin startapp \-\-template=https://github.com/githubuser/django\-app\-template/archive/master.zip myapp
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| When Django copies the app template files, it also renders certain files
 | ||
| through the template engine: the files whose extensions match the
 | ||
| \fB\-\-extension\fP option (\fBpy\fP by default) and the files whose names are passed
 | ||
| with the \fB\-\-name\fP option. The \fBtemplate context\fP used is:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| Any option passed to the \fBstartapp\fP command (among the command\(aqs supported
 | ||
| options)
 | ||
| .IP \(bu 2
 | ||
| \fBapp_name\fP \-\- the app name as passed to the command
 | ||
| .IP \(bu 2
 | ||
| \fBapp_directory\fP \-\- the full path of the newly created app
 | ||
| .IP \(bu 2
 | ||
| \fBcamel_case_app_name\fP \-\- the app name in camel case format
 | ||
| .IP \(bu 2
 | ||
| \fBdocs_version\fP \-\- the version of the documentation: \fB\(aqdev\(aq\fP or \fB\(aq1.x\(aq\fP
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| \fBcamel_case_app_name\fP was added.
 | ||
| 
 | ||
| .sp
 | ||
| \fBWARNING:\fP
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| When the app template files are rendered with the Django template
 | ||
| engine (by default all \fB*.py\fP files), Django will also replace all
 | ||
| stray template variables contained. For example, if one of the Python files
 | ||
| contains a docstring explaining a particular feature related
 | ||
| to template rendering, it might result in an incorrect example.
 | ||
| .sp
 | ||
| To work around this problem, you can use the \fBtemplatetag\fP
 | ||
| templatetag to "escape" the various parts of the template syntax.
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS startproject <projectname> [destination]
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin startproject
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Creates a Django project directory structure for the given project name in
 | ||
| the current directory or the given destination.
 | ||
| .sp
 | ||
| By default, the new directory contains \fBmanage.py\fP and a project package
 | ||
| (containing a \fBsettings.py\fP and other files). See the \fI\%template source\fP for
 | ||
| details.
 | ||
| .sp
 | ||
| If only the project name is given, both the project directory and project
 | ||
| package will be named \fB<projectname>\fP and the project directory
 | ||
| will be created in the current working directory.
 | ||
| .sp
 | ||
| If the optional destination is provided, Django will use that existing
 | ||
| directory as the project directory, and create \fBmanage.py\fP and the project
 | ||
| package within it. Use \(aq.\(aq to denote the current working directory.
 | ||
| .sp
 | ||
| For example:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin startproject myproject /Users/jezdez/Code/myproject_repo
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| As with the \fI\%startapp\fP command, the \fB\-\-template\fP option lets you
 | ||
| specify a directory, file path or URL of a custom project template. See the
 | ||
| \fI\%startapp\fP documentation for details of supported project template
 | ||
| formats.
 | ||
| .sp
 | ||
| For example, this would look for a project template in the given directory
 | ||
| when creating the \fBmyproject\fP project:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin startproject \-\-template=/Users/jezdez/Code/my_project_template myproject
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Django will also accept URLs (\fBhttp\fP, \fBhttps\fP, \fBftp\fP) to compressed
 | ||
| archives with the project template files, downloading and extracting them on the
 | ||
| fly.
 | ||
| .sp
 | ||
| For example, taking advantage of GitHub\(aqs feature to expose repositories as
 | ||
| zip files, you can use a URL like:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin startproject \-\-template=https://github.com/githubuser/django\-project\-template/archive/master.zip myproject
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| When Django copies the project template files, it also renders certain files
 | ||
| through the template engine: the files whose extensions match the
 | ||
| \fB\-\-extension\fP option (\fBpy\fP by default) and the files whose names are passed
 | ||
| with the \fB\-\-name\fP option. The \fBtemplate context\fP used is:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| Any option passed to the \fBstartproject\fP command (among the command\(aqs
 | ||
| supported options)
 | ||
| .IP \(bu 2
 | ||
| \fBproject_name\fP \-\- the project name as passed to the command
 | ||
| .IP \(bu 2
 | ||
| \fBproject_directory\fP \-\- the full path of the newly created project
 | ||
| .IP \(bu 2
 | ||
| \fBsecret_key\fP \-\- a random key for the \fBSECRET_KEY\fP setting
 | ||
| .IP \(bu 2
 | ||
| \fBdocs_version\fP \-\- the version of the documentation: \fB\(aqdev\(aq\fP or \fB\(aq1.x\(aq\fP
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Please also see the \fI\%rendering warning\fP as mentioned
 | ||
| for \fI\%startapp\fP\&.
 | ||
| .SS test <app or test identifier>
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin test
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Runs tests for all installed models. See \fB/topics/testing/index\fP for more
 | ||
| information.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-failfast
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-failfast\fP option can be used to stop running tests and report the
 | ||
| failure immediately after a test fails.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-testrunner
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-testrunner\fP option can be used to control the test runner class that
 | ||
| is used to execute tests. If this value is provided, it overrides the value
 | ||
| provided by the \fBTEST_RUNNER\fP setting.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-liveserver
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fB\-\-liveserver\fP option can be used to override the default address where
 | ||
| the live server (used with \fBLiveServerTestCase\fP) is
 | ||
| expected to run from. The default value is \fBlocalhost:8081\-8179\fP\&.
 | ||
| .sp
 | ||
| In earlier versions, the default value was \fBlocalhost:8081\fP\&.
 | ||
| 
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-keepdb
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-keepdb\fP option can be used to preserve the test database between test
 | ||
| runs. This has the advantage of skipping both the create and destroy actions
 | ||
| which can greatly decrease the time to run tests, especially those in a large
 | ||
| test suite. If the test database does not exist, it will be created on the first
 | ||
| run and then preserved for each subsequent run. Any unapplied migrations will also
 | ||
| be applied to the test database before running the test suite.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-reverse
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-reverse\fP option can be used to sort test cases in the opposite order.
 | ||
| This may help in debugging the side effects of tests that aren\(aqt properly
 | ||
| isolated. Grouping by test class is preserved when using
 | ||
| this option.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-debug\-sql
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-debug\-sql\fP option can be used to enable SQL logging for failing tests. If \fI\%\-\-verbosity\fP is \fB2\fP,
 | ||
| then queries in passing tests are also output.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-parallel
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| The \fB\-\-parallel\fP option can be used to run tests in parallel in separate
 | ||
| processes. Since modern processors have multiple cores, this allows running
 | ||
| tests significantly faster.
 | ||
| .sp
 | ||
| By default \fB\-\-parallel\fP runs one process per core according to
 | ||
| \fI\%multiprocessing.cpu_count()\fP\&. You can adjust the number of processes
 | ||
| either by providing it as the option\(aqs value, e.g. \fB\-\-parallel=4\fP, or by
 | ||
| setting the \fBDJANGO_TEST_PROCESSES\fP environment variable.
 | ||
| .sp
 | ||
| Django distributes test cases — \fI\%unittest.TestCase\fP subclasses — to
 | ||
| subprocesses. If there are fewer test cases than configured processes, Django
 | ||
| will reduce the number of processes accordingly.
 | ||
| .sp
 | ||
| Each process gets its own database. You must ensure that different test cases
 | ||
| don\(aqt access the same resources. For instance, test cases that touch the
 | ||
| filesystem should create a temporary directory for their own use.
 | ||
| .sp
 | ||
| This option requires the third\-party \fBtblib\fP package to display tracebacks
 | ||
| correctly:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| $ pip install tblib
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| This feature isn\(aqt available on Windows. It doesn\(aqt work with the Oracle
 | ||
| database backend either.
 | ||
| .sp
 | ||
| \fBWARNING:\fP
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| When test parallelization is enabled and a test fails, Django may be
 | ||
| unable to display the exception traceback. This can make debugging
 | ||
| difficult. If you encounter this problem, run the affected test without
 | ||
| parallelization to see the traceback of the failure.
 | ||
| .sp
 | ||
| This is a known limitation. It arises from the need to serialize objects
 | ||
| in order to exchange them between processes. See
 | ||
| \fI\%What can be pickled and unpickled?\fP for details.
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS testserver <fixture fixture ...>
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin testserver
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Runs a Django development server (as in \fI\%runserver\fP) using data from
 | ||
| the given fixture(s).
 | ||
| .sp
 | ||
| For example, this command:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin testserver mydata.json
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| \&...would perform the following steps:
 | ||
| .INDENT 0.0
 | ||
| .IP 1. 3
 | ||
| Create a test database, as described in the\-test\-database\&.
 | ||
| .IP 2. 3
 | ||
| Populate the test database with fixture data from the given fixtures.
 | ||
| (For more on fixtures, see the documentation for \fI\%loaddata\fP above.)
 | ||
| .IP 3. 3
 | ||
| Runs the Django development server (as in \fI\%runserver\fP), pointed at
 | ||
| this newly created test database instead of your production database.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| This is useful in a number of ways:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| When you\(aqre writing \fBunit tests\fP of how your views
 | ||
| act with certain fixture data, you can use \fBtestserver\fP to interact with
 | ||
| the views in a Web browser, manually.
 | ||
| .IP \(bu 2
 | ||
| Let\(aqs say you\(aqre developing your Django application and have a "pristine"
 | ||
| copy of a database that you\(aqd like to interact with. You can dump your
 | ||
| database to a fixture (using the \fI\%dumpdata\fP command, explained
 | ||
| above), then use \fBtestserver\fP to run your Web application with that data.
 | ||
| With this arrangement, you have the flexibility of messing up your data
 | ||
| in any way, knowing that whatever data changes you\(aqre making are only
 | ||
| being made to a test database.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Note that this server does \fInot\fP automatically detect changes to your Python
 | ||
| source code (as \fI\%runserver\fP does). It does, however, detect changes to
 | ||
| templates.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-addrport [port number or ipaddr:port]
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use \fB\-\-addrport\fP to specify a different port, or IP address and port, from
 | ||
| the default of \fB127.0.0.1:8000\fP\&. This value follows exactly the same format and
 | ||
| serves exactly the same function as the argument to the \fI\%runserver\fP
 | ||
| command.
 | ||
| .sp
 | ||
| Examples:
 | ||
| .sp
 | ||
| To run the test server on port 7000 with \fBfixture1\fP and \fBfixture2\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin testserver \-\-addrport 7000 fixture1 fixture2
 | ||
| django\-admin testserver fixture1 fixture2 \-\-addrport 7000
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| (The above statements are equivalent. We include both of them to demonstrate
 | ||
| that it doesn\(aqt matter whether the options come before or after the fixture
 | ||
| arguments.)
 | ||
| .sp
 | ||
| To run on 1.2.3.4:7000 with a \fBtest\fP fixture:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin testserver \-\-addrport 1.2.3.4:7000 test
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The \fI\%\-\-noinput\fP option may be provided to suppress all user
 | ||
| prompts.
 | ||
| .SH COMMANDS PROVIDED BY APPLICATIONS
 | ||
| .sp
 | ||
| Some commands are only available when the \fBdjango.contrib\fP application that
 | ||
| \fBimplements\fP them has been
 | ||
| \fBenabled\fP\&. This section describes them grouped by
 | ||
| their application.
 | ||
| .SS \fBdjango.contrib.auth\fP
 | ||
| .SS changepassword
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin changepassword
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| This command is only available if Django\(aqs \fBauthentication system\fP (\fBdjango.contrib.auth\fP) is installed.
 | ||
| .sp
 | ||
| Allows changing a user\(aqs password. It prompts you to enter a new password twice
 | ||
| for the given user. If the entries are identical, this immediately becomes the
 | ||
| new password. If you do not supply a user, the command will attempt to change
 | ||
| the password whose username matches the current user.
 | ||
| .sp
 | ||
| Use the \fB\-\-database\fP option to specify the database to query for the user. If
 | ||
| it\(aqs not supplied, Django will use the \fBdefault\fP database.
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin changepassword ringo
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SS createsuperuser
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin createsuperuser
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| This command is only available if Django\(aqs \fBauthentication system\fP (\fBdjango.contrib.auth\fP) is installed.
 | ||
| .sp
 | ||
| Creates a superuser account (a user who has all permissions). This is
 | ||
| useful if you need to create an initial superuser account or if you need to
 | ||
| programmatically generate superuser accounts for your site(s).
 | ||
| .sp
 | ||
| When run interactively, this command will prompt for a password for
 | ||
| the new superuser account. When run non\-interactively, no password
 | ||
| will be set, and the superuser account will not be able to log in until
 | ||
| a password has been manually set for it.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-username
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-email
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The username and email address for the new account can be supplied by
 | ||
| using the \fB\-\-username\fP and \fB\-\-email\fP arguments on the command
 | ||
| line. If either of those is not supplied, \fBcreatesuperuser\fP will prompt for
 | ||
| it when running interactively.
 | ||
| .sp
 | ||
| Use the \fB\-\-database\fP option to specify the database into which the superuser
 | ||
| object will be saved.
 | ||
| .sp
 | ||
| 
 | ||
| .sp
 | ||
| You can subclass the management command and override \fBget_input_data()\fP if you
 | ||
| want to customize data input and validation. Consult the source code for
 | ||
| details on the existing implementation and the method\(aqs parameters. For example,
 | ||
| it could be useful if you have a \fBForeignKey\fP in
 | ||
| \fBREQUIRED_FIELDS\fP and want to
 | ||
| allow creating an instance instead of entering the primary key of an existing
 | ||
| instance.
 | ||
| .SS \fBdjango.contrib.gis\fP
 | ||
| .SS ogrinspect
 | ||
| .sp
 | ||
| This command is only available if \fBGeoDjango\fP
 | ||
| (\fBdjango.contrib.gis\fP) is installed.
 | ||
| .sp
 | ||
| Please refer to its \fBdescription\fP in the GeoDjango
 | ||
| documentation.
 | ||
| .SS \fBdjango.contrib.sessions\fP
 | ||
| .SS clearsessions
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django\-admin clearsessions
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Can be run as a cron job or directly to clean out expired sessions.
 | ||
| .SS \fBdjango.contrib.sitemaps\fP
 | ||
| .SS ping_google
 | ||
| .sp
 | ||
| This command is only available if the \fBSitemaps framework\fP (\fBdjango.contrib.sitemaps\fP) is installed.
 | ||
| .sp
 | ||
| Please refer to its \fBdescription\fP in the Sitemaps
 | ||
| documentation.
 | ||
| .SS \fBdjango.contrib.staticfiles\fP
 | ||
| .SS collectstatic
 | ||
| .sp
 | ||
| This command is only available if the \fBstatic files application\fP (\fBdjango.contrib.staticfiles\fP) is installed.
 | ||
| .sp
 | ||
| Please refer to its \fBdescription\fP in the
 | ||
| \fBstaticfiles\fP documentation.
 | ||
| .SS findstatic
 | ||
| .sp
 | ||
| This command is only available if the \fBstatic files application\fP (\fBdjango.contrib.staticfiles\fP) is installed.
 | ||
| .sp
 | ||
| Please refer to its \fBdescription\fP in the \fBstaticfiles\fP documentation.
 | ||
| .SH DEFAULT OPTIONS
 | ||
| .sp
 | ||
| Although some commands may allow their own custom options, every command
 | ||
| allows for the following options:
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-pythonpath
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin migrate \-\-pythonpath=\(aq/home/djangoprojects/myproject\(aq
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Adds the given filesystem path to the Python \fI\%import search path\fP\&. If this
 | ||
| isn\(aqt provided, \fBdjango\-admin\fP will use the \fBPYTHONPATH\fP environment
 | ||
| variable.
 | ||
| .sp
 | ||
| Note that this option is unnecessary in \fBmanage.py\fP, because it takes care of
 | ||
| setting the Python path for you.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-settings
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin migrate \-\-settings=mysite.settings
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Explicitly specifies the settings module to use. The settings module should be
 | ||
| in Python package syntax, e.g. \fBmysite.settings\fP\&. If this isn\(aqt provided,
 | ||
| \fBdjango\-admin\fP will use the \fBDJANGO_SETTINGS_MODULE\fP environment
 | ||
| variable.
 | ||
| .sp
 | ||
| Note that this option is unnecessary in \fBmanage.py\fP, because it uses
 | ||
| \fBsettings.py\fP from the current project by default.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-traceback
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin migrate \-\-traceback
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| By default, \fBdjango\-admin\fP will show a simple error message whenever a
 | ||
| \fBCommandError\fP occurs, but a full stack trace
 | ||
| for any other exception. If you specify \fB\-\-traceback\fP, \fBdjango\-admin\fP
 | ||
| will also output a full stack trace when a \fBCommandError\fP is raised.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-verbosity
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin migrate \-\-verbosity 2
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use \fB\-\-verbosity\fP to specify the amount of notification and debug information
 | ||
| that \fBdjango\-admin\fP should print to the console.
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| \fB0\fP means no output.
 | ||
| .IP \(bu 2
 | ||
| \fB1\fP means normal output (default).
 | ||
| .IP \(bu 2
 | ||
| \fB2\fP means verbose output.
 | ||
| .IP \(bu 2
 | ||
| \fB3\fP means \fIvery\fP verbose output.
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-no\-color
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Example usage:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin sqlall \-\-no\-color
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| By default, \fBdjango\-admin\fP will format the output to be colorized. For
 | ||
| example, errors will be printed to the console in red and SQL statements will
 | ||
| be syntax highlighted. To prevent this and have a plain text output, pass the
 | ||
| \fB\-\-no\-color\fP option when running your command.
 | ||
| .SH COMMON OPTIONS
 | ||
| .sp
 | ||
| The following options are not available on every command, but they are common
 | ||
| to a number of commands.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-database
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Used to specify the database on which a command will operate. If not
 | ||
| specified, this option will default to an alias of \fBdefault\fP\&.
 | ||
| .sp
 | ||
| For example, to dump data from the database with the alias \fBmaster\fP:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin dumpdata \-\-database=master
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-exclude
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Exclude a specific application from the applications whose contents is
 | ||
| output. For example, to specifically exclude the \fBauth\fP application from
 | ||
| the output of dumpdata, you would call:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin dumpdata \-\-exclude=auth
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| If you want to exclude multiple applications, use multiple \fB\-\-exclude\fP
 | ||
| directives:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| django\-admin dumpdata \-\-exclude=auth \-\-exclude=contenttypes
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-locale
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-locale\fP or \fB\-l\fP option to specify the locale to process.
 | ||
| If not provided all locales are processed.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \-\-noinput
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Use the \fB\-\-noinput\fP option to suppress all user prompting, such as "Are
 | ||
| you sure?" confirmation messages. This is useful if \fBdjango\-admin\fP is
 | ||
| being executed as an unattended, automated script. You can use \fB\-\-no\-input\fP
 | ||
| as an alias for this option.
 | ||
| .sp
 | ||
| The \fB\-\-no\-input\fP alias was added.
 | ||
| 
 | ||
| .SH EXTRA NICETIES
 | ||
| .SS Syntax coloring
 | ||
| .sp
 | ||
| The \fBdjango\-admin\fP / \fBmanage.py\fP commands will use pretty
 | ||
| color\-coded output if your terminal supports ANSI\-colored output. It
 | ||
| won\(aqt use the color codes if you\(aqre piping the command\(aqs output to
 | ||
| another program.
 | ||
| .sp
 | ||
| Under Windows, the native console doesn\(aqt support ANSI escape sequences so by
 | ||
| default there is no color output. But you can install the \fI\%ANSICON\fP
 | ||
| third\-party tool, the Django commands will detect its presence and will make
 | ||
| use of its services to color output just like on Unix\-based platforms.
 | ||
| .sp
 | ||
| The colors used for syntax highlighting can be customized. Django
 | ||
| ships with three color palettes:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| \fBdark\fP, suited to terminals that show white text on a black
 | ||
| background. This is the default palette.
 | ||
| .IP \(bu 2
 | ||
| \fBlight\fP, suited to terminals that show black text on a white
 | ||
| background.
 | ||
| .IP \(bu 2
 | ||
| \fBnocolor\fP, which disables syntax highlighting.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| You select a palette by setting a \fBDJANGO_COLORS\fP environment
 | ||
| variable to specify the palette you want to use. For example, to
 | ||
| specify the \fBlight\fP palette under a Unix or OS/X BASH shell, you
 | ||
| would run the following at a command prompt:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| export DJANGO_COLORS="light"
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| You can also customize the colors that are used. Django specifies a
 | ||
| number of roles in which color is used:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| \fBerror\fP \- A major error.
 | ||
| .IP \(bu 2
 | ||
| \fBnotice\fP \- A minor error.
 | ||
| .IP \(bu 2
 | ||
| \fBsql_field\fP \- The name of a model field in SQL.
 | ||
| .IP \(bu 2
 | ||
| \fBsql_coltype\fP \- The type of a model field in SQL.
 | ||
| .IP \(bu 2
 | ||
| \fBsql_keyword\fP \- An SQL keyword.
 | ||
| .IP \(bu 2
 | ||
| \fBsql_table\fP \- The name of a model in SQL.
 | ||
| .IP \(bu 2
 | ||
| \fBhttp_info\fP \- A 1XX HTTP Informational server response.
 | ||
| .IP \(bu 2
 | ||
| \fBhttp_success\fP \- A 2XX HTTP Success server response.
 | ||
| .IP \(bu 2
 | ||
| \fBhttp_not_modified\fP \- A 304 HTTP Not Modified server response.
 | ||
| .IP \(bu 2
 | ||
| \fBhttp_redirect\fP \- A 3XX HTTP Redirect server response other than 304.
 | ||
| .IP \(bu 2
 | ||
| \fBhttp_not_found\fP \- A 404 HTTP Not Found server response.
 | ||
| .IP \(bu 2
 | ||
| \fBhttp_bad_request\fP \- A 4XX HTTP Bad Request server response other than 404.
 | ||
| .IP \(bu 2
 | ||
| \fBhttp_server_error\fP \- A 5XX HTTP Server Error response.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Each of these roles can be assigned a specific foreground and
 | ||
| background color, from the following list:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| \fBblack\fP
 | ||
| .IP \(bu 2
 | ||
| \fBred\fP
 | ||
| .IP \(bu 2
 | ||
| \fBgreen\fP
 | ||
| .IP \(bu 2
 | ||
| \fByellow\fP
 | ||
| .IP \(bu 2
 | ||
| \fBblue\fP
 | ||
| .IP \(bu 2
 | ||
| \fBmagenta\fP
 | ||
| .IP \(bu 2
 | ||
| \fBcyan\fP
 | ||
| .IP \(bu 2
 | ||
| \fBwhite\fP
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Each of these colors can then be modified by using the following
 | ||
| display options:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| \fBbold\fP
 | ||
| .IP \(bu 2
 | ||
| \fBunderscore\fP
 | ||
| .IP \(bu 2
 | ||
| \fBblink\fP
 | ||
| .IP \(bu 2
 | ||
| \fBreverse\fP
 | ||
| .IP \(bu 2
 | ||
| \fBconceal\fP
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| A color specification follows one of the following patterns:
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| \fBrole=fg\fP
 | ||
| .IP \(bu 2
 | ||
| \fBrole=fg/bg\fP
 | ||
| .IP \(bu 2
 | ||
| \fBrole=fg,option,option\fP
 | ||
| .IP \(bu 2
 | ||
| \fBrole=fg/bg,option,option\fP
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| where \fBrole\fP is the name of a valid color role, \fBfg\fP is the
 | ||
| foreground color, \fBbg\fP is the background color and each \fBoption\fP
 | ||
| is one of the color modifying options. Multiple color specifications
 | ||
| are then separated by a semicolon. For example:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| would specify that errors be displayed using blinking yellow on blue,
 | ||
| and notices displayed using magenta. All other color roles would be
 | ||
| left uncolored.
 | ||
| .sp
 | ||
| Colors can also be specified by extending a base palette. If you put
 | ||
| a palette name in a color specification, all the colors implied by that
 | ||
| palette will be loaded. So:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| would specify the use of all the colors in the light color palette,
 | ||
| \fIexcept\fP for the colors for errors and notices which would be
 | ||
| overridden as specified.
 | ||
| .SS Bash completion
 | ||
| .sp
 | ||
| If you use the Bash shell, consider installing the Django bash completion
 | ||
| script, which lives in \fBextras/django_bash_completion\fP in the Django
 | ||
| distribution. It enables tab\-completion of \fBdjango\-admin\fP and
 | ||
| \fBmanage.py\fP commands, so you can, for instance...
 | ||
| .INDENT 0.0
 | ||
| .IP \(bu 2
 | ||
| Type \fBdjango\-admin\fP\&.
 | ||
| .IP \(bu 2
 | ||
| Press [TAB] to see all available options.
 | ||
| .IP \(bu 2
 | ||
| Type \fBsql\fP, then [TAB], to see all available options whose names start
 | ||
| with \fBsql\fP\&.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| See \fB/howto/custom\-management\-commands\fP for how to add customized actions.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B django.core.management.call_command(name, *args, **options)
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| To call a management command from code use \fBcall_command\fP\&.
 | ||
| .INDENT 0.0
 | ||
| .TP
 | ||
| .B \fBname\fP
 | ||
| the name of the command to call.
 | ||
| .TP
 | ||
| .B \fB*args\fP
 | ||
| a list of arguments accepted by the command.
 | ||
| .TP
 | ||
| .B \fB**options\fP
 | ||
| named options accepted on the command\-line.
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Examples:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| from django.core import management
 | ||
| management.call_command(\(aqflush\(aq, verbosity=0, interactive=False)
 | ||
| management.call_command(\(aqloaddata\(aq, \(aqtest_data\(aq, verbosity=0)
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| Note that command options that take no arguments are passed as keywords
 | ||
| with \fBTrue\fP or \fBFalse\fP, as you can see with the \fBinteractive\fP option above.
 | ||
| .sp
 | ||
| Named arguments can be passed by using either one of the following syntaxes:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| # Similar to the command line
 | ||
| management.call_command(\(aqdumpdata\(aq, \(aq\-\-natural\-foreign\(aq)
 | ||
| 
 | ||
| # Named argument similar to the command line minus the initial dashes and
 | ||
| # with internal dashes replaced by underscores
 | ||
| management.call_command(\(aqdumpdata\(aq, natural_foreign=True)
 | ||
| 
 | ||
| # \(gause_natural_foreign_keys\(ga is the option destination variable
 | ||
| management.call_command(\(aqdumpdata\(aq, use_natural_foreign_keys=True)
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .sp
 | ||
| The first syntax is now supported thanks to management commands using the
 | ||
| \fI\%argparse\fP module. For the second syntax, Django previously passed
 | ||
| the option name as\-is to the command, now it is always using the \fBdest\fP
 | ||
| variable name (which may or may not be the same as the option name).
 | ||
| 
 | ||
| .sp
 | ||
| Command options which take multiple options are passed a list:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| management.call_command(\(aqdumpdata\(aq, exclude=[\(aqcontenttypes\(aq, \(aqauth\(aq])
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SH OUTPUT REDIRECTION
 | ||
| .sp
 | ||
| Note that you can redirect standard output and error streams as all commands
 | ||
| support the \fBstdout\fP and \fBstderr\fP options. For example, you could write:
 | ||
| .INDENT 0.0
 | ||
| .INDENT 3.5
 | ||
| .sp
 | ||
| .nf
 | ||
| .ft C
 | ||
| with open(\(aq/tmp/command_output\(aq) as f:
 | ||
|     management.call_command(\(aqdumpdata\(aq, stdout=f)
 | ||
| .ft P
 | ||
| .fi
 | ||
| .UNINDENT
 | ||
| .UNINDENT
 | ||
| .SH AUTHOR
 | ||
| Django Software Foundation
 | ||
| .SH COPYRIGHT
 | ||
| Django Software Foundation and contributors
 | ||
| .\" Generated by docutils manpage writer.
 | ||
| .
 |