[soc2009/model-validation] Merget to trunk at r12009

git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/model-validation@12014 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/topics/http/file-uploads.txt

@@ -30,7 +30,7 @@ is a dictionary containing a key for each ``FileField`` (or ``ImageField``, or
 other ``FileField`` subclass) in the form. So the data from the above form would
 be accessible as ``request.FILES['file']``.
 
-Note that ``request.FILES`` will only contain data if the request method was 
+Note that ``request.FILES`` will only contain data if the request method was
 ``POST`` and the ``<form>`` that posted the request has the attribute
 ``enctype="multipart/form-data"``. Otherwise, ``request.FILES`` will be empty.
 
@@ -140,19 +140,19 @@ Three settings control Django's file upload behavior:
 
         Defaults to your system's standard temporary directory (i.e. ``/tmp`` on
         most Unix-like systems).
-        
+
     :setting:`FILE_UPLOAD_PERMISSIONS`
         The numeric mode (i.e. ``0644``) to set newly uploaded files to. For
         more information about what these modes mean, see the `documentation for
         os.chmod`_
-        
+
         If this isn't given or is ``None``, you'll get operating-system
         dependent behavior. On most platforms, temporary files will have a mode
         of ``0600``, and files saved from memory will be saved using the
         system's standard umask.
-        
+
         .. warning::
-        
+
             If you're not familiar with file modes, please note that the leading
             ``0`` is very important: it indicates an octal number, which is the
             way that modes must be specified. If you try to use ``644``, you'll
@@ -173,7 +173,7 @@ Three settings control Django's file upload behavior:
         Which means "try to upload to memory first, then fall back to temporary
         files."
 
-.. _documentation for os.chmod: http://docs.python.org/lib/os-file-dir.html 
+.. _documentation for os.chmod: http://docs.python.org/library/os.html#os.chmod
 
 ``UploadedFile`` objects
 ========================
@@ -197,17 +197,17 @@ define the following methods/attributes:
     ``UploadedFile.temporary_file_path()``
         Only files uploaded onto disk will have this method; it returns the full
         path to the temporary uploaded file.
-        
+
 .. note::
 
     Like regular Python files, you can read the file line-by-line simply by
     iterating over the uploaded file:
-    
+
     .. code-block:: python
-        
+
         for line in uploadedfile:
             do_something_with(line)
-            
+
     However, *unlike* standard Python files, :class:`UploadedFile` only
     understands ``\n`` (also known as "Unix-style") line endings. If you know
     that you need to handle uploaded files with different line endings, you'll

docs/topics/http/sessions.txt

@@ -24,14 +24,6 @@ To enable session functionality, do the following:
       The default ``settings.py`` created by ``django-admin.py startproject`` has
       ``SessionMiddleware`` activated.
 
-    * Add ``'django.contrib.sessions'`` to your ``INSTALLED_APPS`` setting,
-      and run ``manage.py syncdb`` to install the single database table
-      that stores session data.
-
-.. versionchanged:: 1.0
-   This step is optional if you're not using the database session backend;
-   see `configuring the session engine`_.
-
 If you don't want to use sessions, you might as well remove the
 ``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and ``'django.contrib.sessions'``
 from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
@@ -46,6 +38,22 @@ By default, Django stores sessions in your database (using the model
 some setups it's faster to store session data elsewhere, so Django can be
 configured to store session data on your filesystem or in your cache.
 
+Using database-backed sessions
+------------------------------
+
+If you want to use a database-backed session, you need to add
+``'django.contrib.sessions'`` to your ``INSTALLED_APPS`` setting.
+
+If you want to store your session data on a database other than ``default``
+alias, you should set the :setting:`SESSION_DB_ALIAS` setting.
+
+Once you have configured your installation, run ``manage.py syncdb``
+to install the single database table that stores session data.
+
+.. versionadded:: 1.2
+   The :setting:`SESSION_DB_ALIAS` setting was added in Django 1.2. It
+   is not required in earlier versions.
+
 Using cached sessions
 ---------------------
 
@@ -86,6 +94,9 @@ disregards persistence. In most cases, the ``cached_db`` backend will be fast
 enough, but if you need that last bit of performance, and are willing to let
 session data be expunged from time to time, the ``cache`` backend is for you.
 
+If you use the ``cached_db`` session backend, you also need to follow the
+configuration instructions for the `using database-backed sessions`_.
+
 Using file-based sessions
 -------------------------
 
@@ -97,6 +108,7 @@ to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to control
 where Django stores session files. Be sure to check that your Web server has
 permissions to read and write to this location.
 
+
 Using sessions in views
 =======================
 

docs/topics/http/urls.txt

@@ -253,24 +253,30 @@ handler404
 
 .. data:: handler404
 
-A string representing the full Python import path to the view that should be
-called if none of the URL patterns match.
+A callable, or a string representing the full Python import path to the view
+that should be called if none of the URL patterns match.
 
 By default, this is ``'django.views.defaults.page_not_found'``. That default
 value should suffice.
 
+.. versionchanged:: 1.2
+    Previous versions of Django only accepted strings representing import paths.
+
 handler500
 ----------
 
 .. data:: handler500
 
-A string representing the full Python import path to the view that should be
-called in case of server errors. Server errors happen when you have runtime
-errors in view code.
+A callable, or a string representing the full Python import path to the view
+that should be called in case of server errors. Server errors happen when you
+have runtime errors in view code.
 
 By default, this is ``'django.views.defaults.server_error'``. That default
 value should suffice.
 
+.. versionchanged:: 1.2
+    Previous versions of Django only accepted strings representing import paths.
+
 include
 -------