mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00
Code Issues 32 Releases Wiki Activity

[soc2009/multidb] Renaming of database attributes - you now use NAME, ENGINE, etc rather than DATABASE_NAME, DATABASE_ENGINE inside DATABASES. Also deprecates the use of short names (.e.g., `sqlite3` for backends in ENGINE). Patch from Russell Keith-Magee.

Browse Source 
Conflicts:

	docs/releases/1.2.txt

git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/multidb@11775 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Alex Gaynor
2009-11-23 16:45:41 +00:00
parent 3e6ae729bc
commit 4e36fffab2
55 changed files with 628 additions and 425 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/howto/custom-model-fields.txt
View File

@@ -290,13 +290,13 @@ If you aim to build a database-agnostic application, you should account for
differences in database column types. For example, the date/time column type
in PostgreSQL is called ``timestamp``, while the same column in MySQL is called
``datetime``. The simplest way to handle this in a ``db_type()`` method is to
check the ``connection.settings_dict['DATABASE_ENGINE']`` attribute.
check the ``connection.settings_dict['ENGINE']`` attribute.
For example::
class MyDateField(models.Field):
def db_type(self, connection):
if connection.settings_dict['DATABASE_ENGINE'] == 'mysql':
if connection.settings_dict['ENGINE'] == 'django.db.backends.mysql':
return 'datetime'
else:
return 'timestamp'

34
docs/howto/initial-data.txt
View File

@@ -118,23 +118,27 @@ The SQL files are read by the :djadmin:`sqlcustom`, :djadmin:`sqlreset`,
<ref-django-admin>`. Refer to the :ref:`manage.py documentation
<ref-django-admin>` for more information.
Note that if you have multiple SQL data files, there's no guarantee of the order
in which they're executed. The only thing you can assume is that, by the time
your custom data files are executed, all the database tables already will have
been created.
Note that if you have multiple SQL data files, there's no guarantee of
the order in which they're executed. The only thing you can assume is
that, by the time your custom data files are executed, all the
database tables already will have been created.
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 MySQL. For each app, Django
looks for a file called ``<appname>/sql/<modelname>.<backend>.sql``, where
``<appname>`` is your app directory, ``<modelname>`` is the model's name in
lowercase and ``<backend>`` is the value of ``DATABASE_ENGINE`` for the given
database being set up in your settings file (e.g., ``postgresql``, ``mysql``).
There's also a hook for backend-specific SQL data. For example, you
can have separate initial-data files for PostgreSQL and MySQL. For
each app, Django looks for a file called
``<appname>/sql/<modelname>.<backend>.sql``, where ``<appname>`` 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` in your settings file (e.g., if you have defined a
database with an :setting:`ENGINE` value of
``django.db.backends.postgresql``, Django will look for
``<appname>/sql/<modelname>.postgresql.sql``).
Backend-specific SQL data is executed before non-backend-specific SQL data. For
example, if your app contains the files ``sql/person.sql`` and
``sql/person.postgresql.sql`` and you're installing the app on PostgreSQL,
Django will execute the contents of ``sql/person.postgresql.sql`` first, then
``sql/person.sql``.
Backend-specific SQL data is executed before non-backend-specific SQL
data. For example, if your app contains the files ``sql/person.sql``
and ``sql/person.postgresql.sql`` and you're installing the app on
PostgreSQL, Django will execute the contents of
``sql/person.postgresql.sql`` first, then ``sql/person.sql``.

16
docs/howto/legacy-databases.txt
View File

@@ -19,15 +19,15 @@ Give Django your database parameters
You'll need to tell Django what your database connection parameters are, and
what the name of the database is. Do that by editing the :setting:`DATABASES`
setting and assigning values to the following keys in the ``'default'``
dictionary:
setting and assigning values to the following keys for the ``'default'``
connection:
* ``DATABASE_NAME``
* ``DATABASE_ENGINE``
* ``DATABASE_USER``
* ``DATABASE_PASSWORD``
* ``DATABASE_HOST``
* ``DATABASE_PORT``
* :setting:`NAME`
* :setting:`ENGINE`
* :setting:`USER`
* :setting:`PASSWORD`
* :setting:`HOST`
* :setting:`PORT`
Auto-generate the models
========================

24
docs/internals/contributing.txt
View File

@@ -763,18 +763,18 @@ info. Your :setting:`DATABASES` setting needs to define two databases:
want. It doesn't need to use the same backend as the ``default``
database (although it can use the same backend if you want to).
If you're using the ``sqlite3`` database backend, you need to define
:setting:`DATABASE_ENGINE` for both databases, plus a
:setting:`TEST_DATABASE_NAME` for the ``other`` database. The
If you're using the SQLite database backend, you need to define
:setting:`ENGINE` for both databases, plus a
:setting:`TEST_NAME` for the ``other`` database. The
following is a minimal settings file that can be used to test SQLite::
DATABASES = {
'default': {
'DATABASE_ENGINE': 'sqlite3'
'ENGINE': 'django.db.backends.sqlite3'
},
'other': {
'DATABASE_ENGINE': 'sqlite3',
'TEST_DATABASE_NAME: 'other_db'
'ENGINE': 'django.db.backends.sqlite3',
'TEST_NAME: 'other_db'
}
}
@@ -782,22 +782,22 @@ following is a minimal settings file that can be used to test SQLite::
If you're using another backend, you will need to provide other details for
each database:
* The :setting:`DATABASE_USER` option for each of your databases needs to
* The :setting:`USER` option for each of your databases needs to
specify an existing user account for the database.
* The :setting:`DATABASE_PASSWORD` option needs to provide the password for
the :setting:`DATABASE_USER` that has been specified.
* The :setting:`PASSWORD` option needs to provide the password for
the :setting:`USER` that has been specified.
* The :setting:`DATABASE_NAME` option must be the name of an existing database to
* The :setting:`NAME` option must be the name of an existing database to
which the given user has permission to connect. The unit tests will not
touch this database; the test runner creates a new database whose name is
:setting:`DATABASE_NAME` prefixed with ``test_``, and this test database is
:setting:`NAME` prefixed with ``test_``, and this test database is
deleted when the tests are finished. This means your user account needs
permission to execute ``CREATE DATABASE``.
You will also need to ensure that your database uses UTF-8 as the default
character set. If your database server doesn't use UTF-8 as a default charset,
you will need to include a value for ``TEST_DATABASE_CHARSET`` in the settings
you will need to include a value for ``TEST_CHARSET`` in the settings
dictionary for the applicable database.
If you want to run the full suite of tests, you'll need to install a number of

47
docs/intro/tutorial01.txt
View File

@@ -158,35 +158,40 @@ It worked!
Database setup
--------------
Now, edit :file:`settings.py`. It's a normal Python module with module-level
variables representing Django settings. Change the following keys in the
:setting:`DATABASES` ``'default'`` item to match your databases connection
settings.
Now, edit :file:`settings.py`. It's a normal Python module with
module-level variables representing Django settings. Change the
following keys in the :setting:`DATABASES` ``'default'`` item to match
your databases connection settings.
* ``DATABASE_ENGINE`` -- Either 'postgresql_psycopg2', 'mysql' or
'sqlite3'. Other backends are :setting:`also available <DATABASE_ENGINE>`.
* :setting:`ENGINE` -- Either
``'django.db.backends.postgresql_psycopg2'``,
``'django.db.backends.mysql'`` or
``'django.db.backends.sqlite3'``. Other backends are
:setting:`also available <ENGINE>`.
* ``DATABASE_NAME`` -- The name of your database. If you're using
SQLite, the database will be a file on your computer; in that case,
``DATABASE_NAME`` should be the full absolute path, including filename, of
that file. If the file doesn't exist, it will automatically be created
when you synchronize the database for the first time (see below).
* :setting:`NAME` -- The name of your database. If you're using
SQLite, the database will be a file on your computer; in that
case, :setting:`NAME` should be the full absolute path,
including filename, of that file. If the file doesn't exist, it
will automatically be created when you synchronize the database
for the first time (see below).
When specifying the path, always use forward slashes, even on Windows
(e.g. ``C:/homes/user/mysite/sqlite3.db``).
When specifying the path, always use forward slashes, even on
Windows (e.g. ``C:/homes/user/mysite/sqlite3.db``).
* ``DATABASE_USER`` -- Your database username (not used for SQLite).
* :setting:`USER` -- Your database username (not used for SQLite).
* ``DATABASE_PASSWORD`` -- Your database password (not used for
* :setting:`PASSWORD` -- Your database password (not used for
SQLite).
* ``DATABASE_HOST`` -- The host your database is on. Leave this as an
empty string if your database server is on the same physical machine (not
used for SQLite).
* :setting:`HOST` -- The host your database is on. Leave this as
an empty string if your database server is on the same physical
machine (not used for SQLite).
If you're new to databases, we recommend simply using SQLite (by setting
``DATABASE_ENGINE`` to ``'sqlite3'``). SQLite is included as part of
Python 2.5 and later, so you won't need to install anything else.
If you're new to databases, we recommend simply using SQLite (by
setting :setting:`ENGINE` to ``'django.db.backends.sqlite3'``). SQLite
is included as part of Python 2.5 and later, so you won't need to
install anything else.
.. note::

4
docs/man/django-admin.1
View File

@@ -28,8 +28,8 @@ Compiles .po files to .mo files for use with builtin gettext support.
Creates the table needed to use the SQL cache backend
.TP
.B dbshell
Runs the command\-line client for the current
.BI DATABASE_ENGINE.
Runs the command\-line client for the specified
.BI database ENGINE.
.TP
.B diffsettings
Displays differences between the current

87
docs/ref/databases.txt
View File

@@ -44,18 +44,20 @@ Autocommit mode
.. versionadded:: 1.1
If your application is particularly read-heavy and doesn't make many database
writes, the overhead of a constantly open transaction can sometimes be
noticeable. For those situations, if you're using the ``postgresql_psycopg2``
backend, you can configure Django to use *"autocommit"* behavior for the
connection, meaning that each database operation will normally be in its own
transaction, rather than having the transaction extend over multiple
operations. In this case, you can still manually start a transaction if you're
doing something that requires consistency across multiple database operations.
The autocommit behavior is enabled by setting the ``autocommit`` key in the
``DATABASE_OPTIONS`` part of your database in :setting:`DATABASES`::
If your application is particularly read-heavy and doesn't make many
database writes, the overhead of a constantly open transaction can
sometimes be noticeable. For those situations, if you're using the
``postgresql_psycopg2`` backend, you can configure Django to use
*"autocommit"* behavior for the connection, meaning that each database
operation will normally be in its own transaction, rather than having
the transaction extend over multiple operations. In this case, you can
still manually start a transaction if you're doing something that
requires consistency across multiple database operations. The
autocommit behavior is enabled by setting the ``autocommit`` key in
the :setting:`OPTIONS` part of your database configuration in
:setting:`DATABASES`::
DATABASE_OPTIONS = {
OPTIONS = {
"autocommit": True,
}
@@ -67,11 +69,11 @@ objects are changed or none of them are.
.. admonition:: This is database-level autocommit
This functionality is not the same as the
:ref:`topics-db-transactions-autocommit` decorator. That decorator is a
Django-level implementation that commits automatically after data changing
operations. The feature enabled using the ``DATABASE_OPTIONS`` option
provides autocommit behavior at the database adapter level. It commits
after *every* operation.
:ref:`topics-db-transactions-autocommit` decorator. That decorator
is a Django-level implementation that commits automatically after
data changing operations. The feature enabled using the
:setting:`OPTIONS` option provides autocommit behavior at the
database adapter level. It commits after *every* operation.
If you are using this feature and performing an operation akin to delete or
updating that requires multiple operations, you are strongly recommended to
@@ -234,14 +236,13 @@ Refer to the :ref:`settings documentation <ref-settings>`.
Connection settings are used in this order:
1. ``DATABASE_OPTIONS``.
2. ``DATABASE_NAME``, ``DATABASE_USER``,
``DATABASE_PASSWORD``, ``DATABASE_HOST``,
``DATABASE_PORT``
1. :setting:`OPTIONS`.
2. :setting:`NAME`, :setting:`USER`, :setting:`PASSWORD`,
:setting:`HOST`, :setting:`PORT`
3. MySQL option files.
In other words, if you set the name of the database in ``DATABASE_OPTIONS``,
this will take precedence over ``DATABASE_NAME``, which would override
In other words, if you set the name of the database in ``OPTIONS``,
this will take precedence over ``NAME``, which would override
anything in a `MySQL option file`_.
Here's a sample configuration which uses a MySQL option file::
@@ -249,8 +250,8 @@ Here's a sample configuration which uses a MySQL option file::
# settings.py
DATABASES = {
'default': {
'DATABASE_ENGINE': "mysql",
'DATABASE_OPTIONS': {
'ENGINE': 'django.db.backends.mysql',
'OPTIONS': {
'read_default_file': '/path/to/my.cnf',
},
}
@@ -258,9 +259,9 @@ Here's a sample configuration which uses a MySQL option file::
# my.cnf
[client]
database = DATABASE_NAME
user = DATABASE_USER
password = DATABASE_PASSWORD
database = NAME
user = USER
password = PASSWORD
default-character-set = utf8
Several other MySQLdb connection options may be useful, such as ``ssl``,
@@ -291,7 +292,7 @@ storage engine, you have a couple of options.
* Another option is to use the ``init_command`` option for MySQLdb prior to
creating your tables::
DATABASE_OPTIONS = {
OPTIONS = {
"init_command": "SET storage_engine=INNODB",
}
@@ -456,7 +457,7 @@ If you're getting this error, you can solve it by:
* Increase the default timeout value by setting the ``timeout`` database
option option::
DATABASE_OPTIONS = {
OPTIONS = {
# ...
"timeout": 20,
# ...
@@ -511,32 +512,32 @@ Your Django settings.py file should look something like this for Oracle::
DATABASES = {
'default': {
'DATABASE_ENGINE': 'oracle',
'DATABASE_NAME': 'xe',
'DATABASE_USER': 'a_user',
'DATABASE_PASSWORD': 'a_password',
'DATABASE_HOST': '',
'DATABASE_PORT': '' ,
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xe',
'USER': 'a_user',
'PASSWORD': 'a_password',
'HOST': '',
'PORT': '' ,
}
}
If you don't use a ``tnsnames.ora`` file or a similar naming method that
recognizes the SID ("xe" in this example), then fill in both
``DATABASE_HOST`` and ``DATABASE_PORT`` like so::
``HOST`` and ``PORT`` like so::
DATABASES = {
'default': {
'DATABASE_ENGINE': 'oracle',
'DATABASE_NAME': 'xe',
'DATABASE_USER': 'a_user',
'DATABASE_PASSWORD': 'a_password',
'DATABASE_HOST': 'dbprod01ned.mycompany.com',
'DATABASE_PORT': '1540',
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xe',
'USER': 'a_user',
'PASSWORD': 'a_password',
'HOST': 'dbprod01ned.mycompany.com',
'PORT': '1540',
}
}
You should supply both ``DATABASE_HOST`` and ``DATABASE_PORT``, or leave both
You should supply both ``HOST`` and ``PORT``, or leave both
as empty strings.
Tablespace options

6
docs/ref/django-admin.txt
View File

@@ -160,8 +160,8 @@ dbshell
.. django-admin:: dbshell
Runs the command-line client for the database engine specified in your
``DATABASE_ENGINE`` setting, with the connection parameters specified in your
``DATABASE_USER``, ``DATABASE_PASSWORD``, etc., settings.
``ENGINE`` setting, with the connection parameters specified in your
``USER``, ``PASSWORD``, etc., settings.
* For PostgreSQL, this runs the ``psql`` command-line client.
* For MySQL, this runs the ``mysql`` command-line client.
@@ -265,7 +265,7 @@ inspectdb
.. django-admin:: inspectdb
Introspects the database tables in the database pointed-to by the
``DATABASE_NAME`` setting and outputs a Django model module (a ``models.py``
``NAME`` setting and outputs a Django model module (a ``models.py``
file) to standard output.
Use this if you have a legacy database with which you'd like to use Django.

185
docs/ref/settings.txt
View File

@@ -195,41 +195,60 @@ end users) indicating the reason the request was rejected. See
DATABASES
---------
.. versionadded: 1.2
Default: ``{}`` (Empty dictionary)
This is a dictionary containg the settings for all databases to be used with
Django. It is a nested dictionary who's contents maps aliases to a dictionary
containing the options for an individual database. The following inner options
are used:
A dictionary containing the settings for all databases to be used with
Django. It is a nested dictionary who's contents maps database aliases
to a dictionary containing the options for an individual database.
.. deprecated: 1.2
The :setting:`DATABASES` setting must configure a ``default`` database;
any number of additional databases may also be specified.
In versions of Django prior to 1.2 each of the following were
individual settings. The usage of the standalone database settings
has been deprecated, and will be removed in Django 1.4.
The simplest possible settings file is for a single-database setup using
SQLite. This can be configured using the following::
DATABASES = {
'default': {
'BACKEND': 'django.db.backends.sqlite3',
'NAME': 'mydatabase'
}
}
.. setting:: DATABASE_ENGINE
For other database backends, or more complex SQLite configurations, other options
will be required. The following inner options are available.
DATABASE_ENGINE
~~~~~~~~~~~~~~~
.. setting:: ENGINE
ENGINE
~~~~~~
Default: ``''`` (Empty string)
The database backend to use. The built-in database backends are
``'postgresql_psycopg2'``, ``'postgresql'``, ``'mysql'``, ``'sqlite3'``, and
``'oracle'``.
The database backend to use. The built-in database backends are:
* ``'django.db.backends.postgresql_psycopg2'``
* ``'django.db.backends.postgresql'``
* ``'django.db.backends.mysql'``
* ``'django.db.backends.sqlite3'``
* ``'django.db.backends.oracle'``
You can use a database backend that doesn't ship with Django by setting
``DATABASE_ENGINE`` to a fully-qualified path (i.e.
``ENGINE`` to a fully-qualified path (i.e.
``mypackage.backends.whatever``). Writing a whole new database backend from
scratch is left as an exercise to the reader; see the other backends for
examples.
.. versionadded:: 1.0
Support for external database backends is new in 1.0.
.. note::
Prior to Django 1.2, you could use a short version of the backend name
to reference the built-in database backends (e.g., you could use
``'sqlite3'`` to refer to the SQLite backend). This format has been
deprecated, and will be removed in Django 1.4.
DATABASE_HOST
~~~~~~~~~~~~~
.. setting:: HOST
HOST
~~~~
Default: ``''`` (Empty string)
@@ -239,7 +258,7 @@ localhost. Not used with SQLite.
If this value starts with a forward slash (``'/'``) and you're using MySQL,
MySQL will connect via a Unix socket to the specified socket. For example::
"DATABASE_HOST": '/var/run/mysql'
"HOST": '/var/run/mysql'
If you're using MySQL and this value *doesn't* start with a forward slash, then
this value is assumed to be the host.
@@ -249,8 +268,10 @@ for the connection, rather than a network connection to localhost. If you
explicitly need to use a TCP/IP connection on the local machine with
PostgreSQL, specify ``localhost`` here.
DATABASE_NAME
~~~~~~~~~~~~~
.. setting:: NAME
NAME
~~~~
Default: ``''`` (Empty string)
@@ -258,41 +279,48 @@ The name of the database to use. For SQLite, it's the full path to the database
file. When specifying the path, always use forward slashes, even on Windows
(e.g. ``C:/homes/user/mysite/sqlite3.db``).
DATABASE_OPTIONS
~~~~~~~~~~~~~~~~
.. setting:: OPTIONS
OPTIONS
~~~~~~~
Default: ``{}`` (Empty dictionary)
Extra parameters to use when connecting to the database. Consult backend
module's document for available keywords.
DATABASE_PASSWORD
~~~~~~~~~~~~~~~~~
.. setting:: PASSWORD
PASSWORD
~~~~~~~~
Default: ``''`` (Empty string)
The password to use when connecting to the database. Not used with SQLite.
DATABASE_PORT
~~~~~~~~~~~~~
.. setting:: PORT
PORT
~~~~
Default: ``''`` (Empty string)
The port to use when connecting to the database. An empty string means the
default port. Not used with SQLite.
DATABASE_USER
~~~~~~~~~~~~~
.. setting:: USER
USER
~~~~
Default: ``''`` (Empty string)
The username to use when connecting to the database. Not used with SQLite.
.. setting:: TEST_CHARSET
TEST_DATABASE_CHARSET
~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 1.0
TEST_CHARSET
~~~~~~~~~~~~
Default: ``None``
@@ -306,11 +334,10 @@ MySQL_ (``mysql``) backends.
.. _PostgreSQL: http://www.postgresql.org/docs/8.2/static/multibyte.html
.. _MySQL: http://www.mysql.org/doc/refman/5.0/en/charset-database.html
.. setting:: TEST_COLLATION
TEST_DATABASE_COLLATION
~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 1.0
TEST_COLLATION
~~~~~~~~~~~~~~
Default: ``None``
@@ -322,8 +349,10 @@ manual for details).
.. _section 10.3.2: http://www.mysql.org/doc/refman/5.0/en/charset-database.html
TEST_DATABASE_NAME
~~~~~~~~~~~~~~~~~~
.. setting:: TEST_NAME
TEST_NAME
~~~~~~~~~
Default: ``None``
@@ -1292,3 +1321,79 @@ Different locales have different formats. For example, U.S. English would say
See :ttag:`allowed date format strings <now>`. See also ``DATE_FORMAT``,
``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``MONTH_DAY_FORMAT``.
Deprecated settings
===================
.. setting:: DATABASE_ENGINE
DATABASE_ENGINE
---------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`ENGINE` in
:setting:`DATABASES`.
DATABASE_HOST
-------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`HOST` in
:setting:`DATABASES`.
DATABASE_NAME
-------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`NAME` in
:setting:`DATABASES`.
DATABASE_OPTIONS
----------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`OPTIONS` in
:setting:`DATABASES`.
DATABASE_PASSWORD
-----------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`PASSWORD` in
:setting:`DATABASES`.
DATABASE_PORT
-------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`PORT` in
:setting:`DATABASES`.
DATABASE_USER
-------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`USER` in
:setting:`DATABASES`.
TEST_DATABASE_CHARSET
---------------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`TEST_CHARSET` in
:setting:`DATABASES`.
TEST_DATABASE_COLLATION
-----------------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`TEST_COLLATION` in
:setting:`DATABASES`.
TEST_DATABASE_NAME
------------------
.. deprecated:: 1.2
This setting has been replaced by :setting:`TEST_NAME` in
:setting:`DATABASES`.

30
docs/releases/0.96.txt
View File

@@ -96,7 +96,7 @@ support:
* The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to
emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for
other custom SQL -- views, stored procedures, etc.).
* The vestigial ``install`` command has been removed. Use ``syncdb``.
Backslash escaping changed
@@ -179,20 +179,20 @@ strings that referred to callables were allowed). This allows a much more
natural use of URLconfs. For example, this URLconf::
from django.conf.urls.defaults import *
urlpatterns = patterns('',
urlpatterns = patterns('',
('^myview/$', 'mysite.myapp.views.myview')
)
can now be rewritten as::
from django.conf.urls.defaults import *
from mysite.myapp.views import myview
urlpatterns = patterns('',
urlpatterns = patterns('',
('^myview/$', myview)
)
One useful application of this can be seen when using decorators; this
change allows you to apply decorators to views *in your
URLconf*. Thus, you can make a generic view require login very
@@ -202,17 +202,17 @@ easily::
from django.contrib.auth.decorators import login_required
from django.views.generic.list_detail import object_list
from mysite.myapp.models import MyModel
info = {
"queryset" : MyModel.objects.all(),
}
urlpatterns = patterns('',
urlpatterns = patterns('',
('^myview/$', login_required(object_list), info)
)
Note that both syntaxes (strings and callables) are valid, and will continue to
be valid for the foreseeable future.
be valid for the foreseeable future.
The test framework
------------------
@@ -248,19 +248,19 @@ all their hard work:
* Russell Keith-Magee and Malcolm Tredinnick for their major code
contributions. This release wouldn't have been possible without them.
* Our new release manager, James Bennett, for his work in getting out
0.95.1, 0.96, and (hopefully) future release.
* Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill,
Michael Radziej, and Gary Wilson. They agreed to take on the monumental
task of wrangling our tickets into nicely cataloged submission. Figuring
out what to work on is now about a million times easier; thanks again,
guys.
* Everyone who submitted a bug report, patch or ticket comment. We can't
possibly thank everyone by name -- over 200 developers submitted patches
that went into 0.96 -- but everyone who's contributed to Django is listed
in AUTHORS_.
.. _AUTHORS: http://code.djangoproject.com/browser/django/trunk/AUTHORS

75
docs/releases/1.2.txt
View File

@@ -67,6 +67,72 @@ changes:
__members__ = property(lambda self: self.__dir__())
Specifying databases
--------------------
Prior to Django 1.1, Django used a number of settings to control access to a
single database. Django 1.2 introduces support for multiple databases, and as
a result, the way you define database settings has changed.
Previously, there were a number of ``DATABASE_`` settings at the top level of
your settings file. For example::
DATABASE_NAME = 'test_db'
DATABASE_BACKEND = 'postgresl_psycopg2'
DATABASE_USER = 'myusername'
DATABASE_PASSWORD = 's3krit'
These settings are now contained inside a dictionary named
``DATABASES``. Each item in the dictionary corresponds to a single
database connection, with the name ``default`` describing the default
database connection. The setting names have also been shortened to
reflect the fact that they are stored in a dictionary. The sample
settings given previously would now be stored using::
DATABASES = {
'default': {
'NAME': 'test_db',
'BACKEND': 'django.db.backends.postgresl_psycopg2',
'USER': 'myusername',
'PASSWORD': 's3krit',
}
This affects the following settings:
Old setting New Setting
========================================= ===========
:setting:`DATABASE_ENGINE` ENGINE
:setting:`DATABASE_HOST` HOST
:setting:`DATABASE_NAME` NAME
:setting:`DATABASE_OPTIONS` OPTIONS
:setting:`DATABASE_PASSWORD` PASSWORD
:setting:`DATABASE_PORT` PORT
:setting:`DATABASE_USER` USER
:setting:`TEST_DATABASE_CHARSET` TEST_CHARSET
:setting:`TEST_DATABASE_COLLATION` TEST_COLLATION
:setting:`TEST_DATABASE_NAME` TEST_NAME
These changes are also required if you have manually created a database
connection using
In addition to the change in structure, Django 1.2 removes the special
handling for the built-in database backends. All database backends
must now be specified by a fully qualified class name (i.e.,
``django.db.backends.postgresl_psycopg2``, rather than just
``postgresql_psycopg2``)
``__dict__`` on Model instances
-------------------------------
Historically, the ``__dict__`` attribute of a model instance has only contained
attributes corresponding to the fields on a model.
In order to support multiple database configurations, Django 1.2 has
added a ``_state`` attribute to object instances. This attribute will
appear in ``__dict__`` for a model instance. If your code relies on
iterating over __dict__ to obtain a list of fields, you must now
filter out ``_state`` attribute of out ``__dict__``.
.. _deprecated-features-1.2:
Features deprecated in 1.2
@@ -107,3 +173,12 @@ backend implementations that allow you to send email to a
:ref:`memory<topic-email-memory-backend>` - you can even configure all
email to be :ref:`thrown away<topic-email-console-backend>`.
Support for multiple databases
------------------------------
Django 1.2 adds the ability to use :ref:`more than one database
<topics-db-multi-db>`in your Django project. Queries can be
issued at a specific database with the `using()` method on
querysets; individual objects can be saved to a specific database
by providing a ``using`` argument when you save the instance.

79
docs/topics/testing.txt
View File

@@ -278,33 +278,35 @@ The test database
-----------------
Tests that require a database (namely, model tests) will not use your "real"
(production) database. A separate, blank database is created for the tests.
(production) database. Separate, blank databases are created for the tests.
Regardless of whether the tests pass or fail, the test database is destroyed
Regardless of whether the tests pass or fail, the test databases are destroyed
when all the tests have been executed.
By default this test database gets its name by prepending ``test_`` to the
value of the ``DATABASE_NAME`` setting. When using the SQLite database
engine the tests will by default use an in-memory database (i.e., the database
will be created in memory, bypassing the filesystem entirely!). If you want to
use a different database name, specify ``TEST_DATABASE_NAME`` in the dictionary
for any given database in :setting:`DATABASES`.
By default the test databases get their names by prepending ``test_``
to the value of the :setting:`NAME`` settings for the databased
defined in :setting:`DATABASES`. When using the SQLite database engine
the tests will by default use an in-memory database (i.e., the
database will be created in memory, bypassing the filesystem
entirely!). If you want to use a different database name, specify
``TEST_NAME`` in the dictionary for any given database in
:setting:`DATABASES`.
Aside from using a separate database, the test runner will otherwise use all of
the same database settings you have in your settings file:
``DATABASE_ENGINE``, ``DATABASE_USER``, ``DATABASE_HOST``,
etc. The test database is created by the user specified by
``DATABASE_USER``, so you'll need to make sure that the given user
account has sufficient privileges to create a new database on the system.
Aside from using a separate database, the test runner will otherwise
use all of the same database settings you have in your settings file:
:setting:`ENGINE`, :setting:`USER`, :setting:`HOST`, etc. The test
database is created by the user specified by ``USER``, so you'll need
to make sure that the given user account has sufficient privileges to
create a new database on the system.
.. versionadded:: 1.0
For fine-grained control over the
character encoding of your test database, use the
``TEST_DATABASE_CHARSET`` option. If you're using MySQL, you can also
use the ``TEST_DATABASE_COLLATION`` option to control the particular
collation used by the test database. See the :ref:`settings documentation
<ref-settings>` for details of these advanced settings.
For fine-grained control over the character encoding of your test
database, use the :setting:`TEST_CHARSET` option. If you're using
MySQL, you can also use the :setting:`TEST_COLLATION` option to
control the particular collation used by the test database. See the
:ref:`settings documentation <ref-settings>` for details of these
advanced settings.
Other test conditions
---------------------
@@ -1284,16 +1286,17 @@ utility methods in the ``django.test.utils`` module.
.. function:: setup_test_environment()
Performs any global pre-test setup, such as the installing the
instrumentation of the template rendering system and setting up the dummy
``SMTPConnection``.
instrumentation of the template rendering system and setting up
the dummy ``SMTPConnection``.
.. function:: teardown_test_environment()
Performs any global post-test teardown, such as removing the black magic
hooks into the template system and restoring normal e-mail services.
Performs any global post-test teardown, such as removing the black
magic hooks into the template system and restoring normal e-mail
services.
The creation module of the database backend (``connection.creation``) also
provides some utilities that can be useful during testing.
The creation module of the database backend (``connection.creation``)
also provides some utilities that can be useful during testing.
.. function:: create_test_db(verbosity=1, autoclobber=False)
@@ -1301,27 +1304,29 @@ provides some utilities that can be useful during testing.
``verbosity`` has the same behavior as in ``run_tests()``.
``autoclobber`` describes the behavior that will occur if a database with
the same name as the test database is discovered:
``autoclobber`` describes the behavior that will occur if a
database with the same name as the test database is discovered:
* If ``autoclobber`` is ``False``, the user will be asked to approve
destroying the existing database. ``sys.exit`` is called if the user
does not approve.
* If ``autoclobber`` is ``False``, the user will be asked to
approve destroying the existing database. ``sys.exit`` is
called if the user does not approve.
* If autoclobber is ``True``, the database will be destroyed without
consulting the user.
* If autoclobber is ``True``, the database will be destroyed
without consulting the user.
Returns the name of the test database that it created.
``create_test_db()`` has the side effect of modifying
``settings.DATABASE_NAME`` to match the name of the test database.
``create_test_db()`` has the side effect of modifying the value of
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
database.
.. versionchanged:: 1.0
``create_test_db()`` now returns the name of the test database.
.. function:: destroy_test_db(old_database_name, verbosity=1)
Destroys the database whose name is in the :setting:`DATABASE_NAME` setting
and restores the value of :setting:`DATABASE_NAME` to the provided name.
Destroys the database whose name is in stored in :setting:`NAME` in the
:setting:`DATABASES`, and sets :setting:`NAME` to use the
provided name.
``verbosity`` has the same behavior as in ``run_tests()``.