[soc2009/multidb] Merged in all of Justin Bronn's GIS work. Multidb should now work fully with GIS. This is backwards incompatible, if you are using GIS, your ENGINE setting should now be django.contrib.gis.db.backends.XXX where XXX is the name of your DB backend. Thanks to Justin for all his work. This also resolves merge conflicts from the previous commit.

git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/multidb@11813 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2025-10-23 21:59:11 +00:00 · 2009-12-12 02:13:30 +00:00
parent c88113683d
commit 049dc42bde
109 changed files with 2733 additions and 3662 deletions
--- a/docs/internals/deprecation.txt
+++ b/docs/internals/deprecation.txt
@@ -13,13 +13,10 @@ their deprecation, as per the :ref:`Django deprecation policy
          hooking up admin URLs.  This has been deprecated since the 1.1
          release.

-<<<<<<< HEAD:docs/internals/deprecation.txt
-=======
        * Authentication backends need to define the boolean attribute
          ``supports_object_permissions``. The old backend style is deprecated
          since the 1.2 release.

->>>>>>> master:docs/internals/deprecation.txt
    * 1.4
        * ``CsrfResponseMiddleware``.  This has been deprecated since the 1.2
          release, in favour of the template tag method for inserting the CSRF
@@ -33,7 +30,6 @@ their deprecation, as per the :ref:`Django deprecation policy
          class in favor of a generic E-mail backend API.

        * The many to many SQL generation functions on the database backends
-<<<<<<< HEAD:docs/internals/deprecation.txt
          will be removed.

        * The ability to use the ``DATABASE_*`` family of top-level settings to
@@ -47,9 +43,6 @@ their deprecation, as per the :ref:`Django deprecation policy
          ``get_db_prep_lookup`` methods on Field were modified in 1.2 to support
          multiple databases. In 1.4, the support functions that allow methods
          with the old prototype to continue working will be removed.
-=======
-          will be removed.  These have been deprecated since the 1.2 release.
->>>>>>> master:docs/internals/deprecation.txt

        * The ``Message`` model (in ``django.contrib.auth``), its related
          manager in the ``User`` model (``user.message_set``), and the
@@ -59,13 +52,10 @@ their deprecation, as per the :ref:`Django deprecation policy
          :ref:`messages framework <ref-contrib-messages>` should be used 
          instead.

-<<<<<<< HEAD:docs/internals/deprecation.txt
-=======
        * Authentication backends need to support the ``obj`` parameter for
          permission checking. The ``supports_object_permissions`` variable
          is not checked any longer and can be removed.

->>>>>>> master:docs/internals/deprecation.txt
    * 2.0
        * ``django.views.defaults.shortcut()``. This function has been moved
          to ``django.contrib.contenttypes.views.shortcut()`` as part of the
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -257,10 +257,7 @@ Here's a sample configuration which uses a MySQL option file::
        }
    }

-<<<<<<< HEAD:docs/ref/databases.txt

-=======
->>>>>>> master:docs/ref/databases.txt
    # my.cnf
    [client]
    database = NAME
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -210,24 +210,6 @@ records to dump. If you're using a :ref:`custom manager <custom-managers>` as
 the default manager and it filters some of the available records, not all of the
 objects will be dumped.

-<<<<<<< HEAD:docs/ref/django-admin.txt
-=======
-.. django-admin-option:: --exclude
-
-.. versionadded:: 1.0
-
-Exclude a specific application from the applications whose contents is
-output. For example, to specifically exclude the `auth` application from
-the output, you would call::
-
-    django-admin.py dumpdata --exclude=auth
-
-If you want to exclude multiple applications, use multiple ``--exclude``
-directives::
-
-    django-admin.py dumpdata --exclude=auth --exclude=contenttypes
-
->>>>>>> master:docs/ref/django-admin.txt
 .. django-admin-option:: --format <fmt>

 By default, ``dumpdata`` will format its output in JSON, but you can use the
@@ -239,14 +221,11 @@ are listed in :ref:`serialization-formats`.
 By default, ``dumpdata`` will output all data on a single line. This isn't
 easy for humans to read, so you can use the ``--indent`` option to
 pretty-print the output with a number of indentation spaces.
-<<<<<<< HEAD:docs/ref/django-admin.txt

 .. versionadded:: 1.0

 The :djadminopt:`--exclude` option may be provided to prevent specific
 applications from being dumped.
-=======
->>>>>>> master:docs/ref/django-admin.txt

 .. versionadded:: 1.1

@@ -273,15 +252,12 @@ fixture will be re-installed.

 The :djadminopt:`--noinput` option may be provided to suppress all user
 prompts.
-<<<<<<< HEAD:docs/ref/django-admin.txt

 .. versionadded:: 1.2

 The :djadminopt:`--database` option may be used to specify the database
 to flush.

-=======
->>>>>>> master:docs/ref/django-admin.txt

 inspectdb
 ---------
@@ -511,7 +487,6 @@ reset <appname appname ...>
 ---------------------------

 .. django-admin:: reset
-<<<<<<< HEAD:docs/ref/django-admin.txt

 Executes the equivalent of ``sqlreset`` for the given app name(s).

@@ -522,13 +497,6 @@ prompts.

 The :djadminopt:`--database` option can be used to specify the alias
 of the database to reset.
-=======
-
-Executes the equivalent of ``sqlreset`` for the given app name(s).
-
-The :djadminopt:`--noinput` option may be provided to suppress all user
-prompts.
->>>>>>> master:docs/ref/django-admin.txt

 runfcgi [options]
 -----------------
@@ -712,14 +680,11 @@ sqlflush

 Prints the SQL statements that would be executed for the :djadmin:`flush`
 command.
-<<<<<<< HEAD:docs/ref/django-admin.txt

 .. versionadded:: 1.2

 The :djadminopt:`--database` option can be used to specify the database for
 which to print the SQL.
-=======
->>>>>>> master:docs/ref/django-admin.txt

 sqlindexes <appname appname ...>
 --------------------------------
@@ -819,7 +784,6 @@ with an appropriate extension (e.g. ``json`` or ``xml``). See the
 documentation for ``loaddata`` for details on the specification of fixture
 data files.

-<<<<<<< HEAD:docs/ref/django-admin.txt
 --noinput
 ~~~~~~~~~
 The :djadminopt:`--noinput` option may be provided to suppress all user
@@ -829,27 +793,15 @@ prompts.

 The :djadminopt:`--database` option can be used to specify the database to
 synchronize.
-=======
-The :djadminopt:`--noinput` option may be provided to suppress all user
-prompts.

 test <app or test identifier>
 -----------------------------

-.. django-admin:: test
->>>>>>> master:docs/ref/django-admin.txt
-
-test <app or test identifier>
-----------------------------
-
-<<<<<<< HEAD:docs/ref/django-admin.txt
 .. django-admin:: test

 Runs tests for all installed models. See :ref:`topics-testing` for more
 information.

-=======
->>>>>>> master:docs/ref/django-admin.txt
 testserver <fixture fixture ...>
 --------------------------------

@@ -983,7 +935,6 @@ Common options
 The following options are not available on every commands, but they are
 common to a number of commands.

-<<<<<<< HEAD:docs/ref/django-admin.txt
 .. django-admin-option:: --database

 .. versionadded:: 1.2
@@ -1008,8 +959,6 @@ directives::

    django-admin.py dumpdata --exclude=auth --exclude=contenttypes

-=======
->>>>>>> master:docs/ref/django-admin.txt
 .. django-admin-option:: --locale

 Use the ``--locale`` or ``-l`` option to specify the locale to process.
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -145,54 +145,6 @@ The default number of seconds to cache a page when the caching middleware or
 ``cache_page()`` decorator is used.

 .. setting:: CSRF_COOKIE_NAME
-<<<<<<< HEAD:docs/ref/settings.txt
-=======
-
-CSRF_COOKIE_NAME
----------------
-
-.. versionadded:: 1.2
-
-Default: ``'csrftoken'``
-
-The name of the cookie to use for the CSRF authentication token. This can be whatever you
-want.  See :ref:`ref-contrib-csrf`.
-
-.. setting:: CSRF_COOKIE_DOMAIN
-
-CSRF_COOKIE_DOMAIN
------------------
-
-.. versionadded:: 1.2
-
-Default: ``None``
-
-The domain to be used when setting the CSRF cookie.  This can be useful for
-allowing cross-subdomain requests to be exluded from the normal cross site
-request forgery protection.  It should be set to a string such as
-``".lawrence.com"`` to allow a POST request from a form on one subdomain to be
-accepted by accepted by a view served from another subdomain.
-
-.. setting:: CSRF_FAILURE_VIEW
-
-CSRF_FAILURE_VIEW
-----------------
-
-.. versionadded:: 1.2
-
-Default: ``'django.views.csrf.csrf_failure'``
-
-A dotted path to the view function to be used when an incoming request
-is rejected by the CSRF protection.  The function should have this signature::
-
-  def csrf_failure(request, reason="")
-
-where ``reason`` is a short message (intended for developers or logging, not for
-end users) indicating the reason the request was rejected.  See
-:ref:`ref-contrib-csrf`.
-
-.. setting:: DATABASE_ENGINE
->>>>>>> master:docs/ref/settings.txt

 CSRF_COOKIE_NAME
 ----------------
--- a/docs/releases/1.2.txt
+++ b/docs/releases/1.2.txt
@@ -42,8 +42,6 @@ changes that developers must be aware of:
 * All of the CSRF has moved from contrib to core (with backwards compatible
   imports in the old locations, which are deprecated).

-<<<<<<< HEAD:docs/releases/1.2.txt
-=======
 :ttag:`if` tag changes
 ----------------------

@@ -53,7 +51,6 @@ cases even though these strings were normally treated as keywords.  Now, the
 keyword status is always enforced, and template code like ``{% if not %}`` or
 ``{% if and %}`` will throw a TemplateSyntaxError.

->>>>>>> master:docs/releases/1.2.txt
 ``LazyObject``
 --------------

@@ -79,7 +76,6 @@ changes:

       __members__ = property(lambda self: self.__dir__())

-<<<<<<< HEAD:docs/releases/1.2.txt
 Specifying databases
 --------------------

@@ -221,8 +217,6 @@ connection, you should be able to upgrade by renaming
 database specific conversions, then you will need to provide an
 implementation ``get_db_prep_*`` that uses the ``connection``
 argument to resolve database-specific values.
-=======
->>>>>>> master:docs/releases/1.2.txt

 .. _deprecated-features-1.2:

@@ -353,7 +347,6 @@ replaces the deprecated user message API and allows you to temporarily store
 messages in one request and retrieve them for display in a subsequent request
 (usually the next one).

-<<<<<<< HEAD:docs/releases/1.2.txt
 Support for multiple databases
 ------------------------------

@@ -362,7 +355,7 @@ Django 1.2 adds the ability to use :ref:`more than one database
 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.
-=======
+
 'Smart' if tag
 --------------

@@ -396,4 +389,3 @@ Also, filters may now be used in the ``if`` expression. For example:
          class="highlight"
        {% endif %}
      >{{ message }}</div>
->>>>>>> master:docs/releases/1.2.txt
--- a/docs/topics/auth.txt
+++ b/docs/topics/auth.txt
@@ -239,14 +239,11 @@ Methods
        where each perm is in the format 
        ``"<app label>.<permission codename>"``. If the user is inactive,
        this method will always return ``False``.
-<<<<<<< HEAD:docs/topics/auth.txt
-=======

        .. versionadded:: 1.2

        If ``obj`` is passed in, this method won't check for permissions for
        the model, but for the specific object.
->>>>>>> master:docs/topics/auth.txt

    .. method:: models.User.has_module_perms(package_name)