Used app_label instead of appname.

The last component of the dotted path to the application module is
consistently referenced as the application "label". For instance it's
AppConfig.label. appname could be confused with AppConfig.name, which is
the full dotted path.
This commit is contained in:
Aymeric Augustin 2013-12-28 09:53:02 +01:00
parent a7add2f296
commit c81fae6b95
14 changed files with 75 additions and 71 deletions

View file

@ -199,8 +199,8 @@ All attributes can be set in your derived class and can be used in
A string listing the arguments accepted by the command,
suitable for use in help messages; e.g., a command which takes
a list of application names might set this to '<appname
appname ...>'.
a list of application names might set this to '<app_label
app_label ...>'.
.. attribute:: BaseCommand.can_import_settings

View file

@ -150,13 +150,13 @@ Database-backend-specific SQL data
There's also a hook for backend-specific SQL data. For example, you
can have separate initial-data files for PostgreSQL and SQLite. For
each app, Django looks for a file called
``<appname>/sql/<modelname>.<backend>.sql``, where ``<appname>`` is
``<app_label>/sql/<modelname>.<backend>.sql``, where ``<app_label>`` is
your app directory, ``<modelname>`` is the model's name in lowercase
and ``<backend>`` is the last part of the module name provided for the
:setting:`ENGINE <DATABASE-ENGINE>` in your settings file (e.g., if you have
defined a database with an :setting:`ENGINE <DATABASE-ENGINE>` value of
``django.db.backends.sqlite3``, Django will look for
``<appname>/sql/<modelname>.sqlite3.sql``).
``<app_label>/sql/<modelname>.sqlite3.sql``).
Backend-specific SQL data is executed before non-backend-specific SQL
data. For example, if your app contains the files ``sql/person.sql``