mirror of
https://github.com/django/django.git
synced 2025-10-26 15:16:09 +00:00
newforms-admin: Merged from trunk up to [7917].
git-svn-id: http://code.djangoproject.com/svn/django/branches/newforms-admin@7922 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
@@ -738,6 +738,11 @@ If you're using another backend:
|
||||
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 your settings
|
||||
file.
|
||||
|
||||
If you want to run the full suite of tests, you'll need to install a number of
|
||||
dependencies:
|
||||
|
||||
|
||||
@@ -2212,6 +2212,18 @@ updated is that it can only access one database table, the model's main
|
||||
table. So don't try to filter based on related fields or anything like that;
|
||||
it won't work.
|
||||
|
||||
Be aware that the ``update()`` method is converted directly to an SQL
|
||||
statement. It is a bulk operation for direct updates. It doesn't run any
|
||||
``save()`` methods on your models, or emit the ``pre_save`` or ``post_save``
|
||||
signals (which are a consequence of calling ``save()``). If you want to save
|
||||
every item in a ``QuerySet`` and make sure that the ``save()`` method is
|
||||
called on each instance, you don't need any special function to handle that.
|
||||
Just loop over them and call ``save()``:
|
||||
|
||||
for item in my_queryset:
|
||||
item.save()
|
||||
|
||||
|
||||
Extra instance methods
|
||||
======================
|
||||
|
||||
|
||||
@@ -89,7 +89,7 @@ read Python's official documentation for the details.
|
||||
For example, this function has a docstring that describes what it does::
|
||||
|
||||
def add_two(num):
|
||||
"Adds 2 to the given number and returns the result."
|
||||
"Return the result of adding two to the provided number."
|
||||
return num + 2
|
||||
|
||||
Because tests often make great documentation, putting tests directly in
|
||||
@@ -600,8 +600,6 @@ Specifically, a ``Response`` object has the following attributes:
|
||||
``context`` will be a list of ``Context``
|
||||
objects, in the order in which they were rendered.
|
||||
|
||||
``headers`` The HTTP headers of the response. This is a dictionary.
|
||||
|
||||
``request`` The request data that stimulated the response.
|
||||
|
||||
``status_code`` The HTTP status of the response, as an integer. See
|
||||
@@ -619,6 +617,10 @@ Specifically, a ``Response`` object has the following attributes:
|
||||
which they were rendered.
|
||||
=============== ==========================================================
|
||||
|
||||
You can also use dictionary syntax on the response object to query the value
|
||||
of any settings in the HTTP headers. For example, you could determine the
|
||||
content type of a response using ``response['Content-Type']``.
|
||||
|
||||
.. _RFC2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
|
||||
.. _template inheritance: ../templates/#template-inheritance
|
||||
|
||||
|
||||
@@ -146,7 +146,7 @@ database's connection parameters:
|
||||
* ``DATABASE_ENGINE`` -- Either 'postgresql_psycopg2', 'mysql' or 'sqlite3'.
|
||||
Other backends are `also available`_.
|
||||
* ``DATABASE_NAME`` -- The name of your database, or the full (absolute)
|
||||
path to the database file if you're using SQLite.
|
||||
path to the database file if you're using SQLite.
|
||||
* ``DATABASE_USER`` -- Your database username (not used for SQLite).
|
||||
* ``DATABASE_PASSWORD`` -- Your database password (not used for SQLite).
|
||||
* ``DATABASE_HOST`` -- The host your database is on. Leave this as an
|
||||
@@ -161,6 +161,9 @@ database's connection parameters:
|
||||
this point. Do that with "``CREATE DATABASE database_name;``" within your
|
||||
database's interactive prompt.
|
||||
|
||||
If you're using SQLite, you don't need to create anything beforehand - the
|
||||
database file will be created automatically when it is needed.
|
||||
|
||||
While you're editing ``settings.py``, take note of the ``INSTALLED_APPS``
|
||||
setting towards the bottom of the file. That variable holds the names of all
|
||||
Django applications that are activated in this Django instance. Apps can be
|
||||
|
||||
Reference in New Issue
Block a user