[soc2009/multidb] Merged up to trunk r11760.

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

django/contrib/gis/tests/relatedapp/tests.py

@@ -279,11 +279,11 @@ class RelatedGeoModelTest(unittest.TestCase):
     def test14_collect(self):
         "Testing the `collect` GeoQuerySet method and `Collect` aggregate."
         # Reference query:
-        # SELECT AsText(ST_Collect("relatedapp_location"."point")) FROM "relatedapp_city" LEFT OUTER JOIN
+        # SELECT AsText(ST_Collect("relatedapp_location"."point")) FROM "relatedapp_city" LEFT OUTER JOIN 
-        #    "relatedapp_location" ON ("relatedapp_city"."location_id" = "relatedapp_location"."id")
+        #    "relatedapp_location" ON ("relatedapp_city"."location_id" = "relatedapp_location"."id") 
         #    WHERE "relatedapp_city"."state" = 'TX';
         ref_geom = fromstr('MULTIPOINT(-97.516111 33.058333,-96.801611 32.782057,-95.363151 29.763374,-96.801611 32.782057)')
-
+        
         c1 = City.objects.filter(state='TX').collect(field_name='location__point')
         c2 = City.objects.filter(state='TX').aggregate(Collect('location__point'))['location__point__collect']
 
@@ -293,7 +293,6 @@ class RelatedGeoModelTest(unittest.TestCase):
             self.assertEqual(4, len(coll))
             self.assertEqual(ref_geom, coll)
 
-
     # TODO: Related tests for KML, GML, and distance lookups.
 
 def suite():

docs/index.txt

@@ -202,5 +202,5 @@ The Django open-source project
 
     * **Django over time:**
       :ref:`API stability <misc-api-stability>` |
-      :ref:`Release notes <releases-index>` |
+      :ref:`Release notes and upgrading instructions <releases-index>` |
       :ref:`Deprecation Timeline <internals-deprecation>`

docs/ref/contrib/csrf.txt

@@ -46,7 +46,7 @@ To enable CSRF protection for your views, follow these steps:
        ``django.views.decorators.csrf.csrf_protect`` on particular views you
        want to protect (see below).
 
-    2. In any template that uses a POST form, use the ``csrf_token`` tag inside
+    2. In any template that uses a POST form, use the :ttag:`csrf_token` tag inside
        the ``<form>`` element if the form is for an internal URL, e.g.::
 
            <form action="" method="POST">{% csrf_token %}
@@ -123,14 +123,14 @@ as ``CsrfResponseMiddleware``, and it can be used by following these steps:
 
        ``CsrfResponseMiddleware`` needs to process the response before things
        like compression or setting ofETags happen to the response, so it must
-       come after ``GZipMiddleware``, ``CommonMiddleware`` and 
+       come after ``GZipMiddleware``, ``CommonMiddleware`` and
        ``ConditionalGetMiddleware`` in the list. It also must come after
        ``CsrfViewMiddleware``.
 
 Use of the ``CsrfResponseMiddleware`` is not recommended because of the
 performance hit it imposes, and because of a potential security problem (see
 below).  It can be used as an interim measure until applications have been
-updated to use the ``{% csrf_token %}`` tag.  It is deprecated and will be
+updated to use the :ttag:`csrf_token` tag.  It is deprecated and will be
 removed in Django 1.4.
 
 Django 1.1 and earlier provided a single ``CsrfMiddleware`` class.  This is also
@@ -199,7 +199,7 @@ Note that contrib apps, such as the admin, have been updated to use the
 ``CsrfViewMiddleware`` to your settings.  However, if you have supplied
 customised templates to any of the view functions of contrib apps (whether
 explicitly via a keyword argument, or by overriding built-in templates), **you
-MUST update them** to include the ``csrf_token`` template tag as described
+MUST update them** to include the :ttag:`csrf_token` template tag as described
 above, or they will stop working.  (If you cannot update these templates for
 some reason, you will be forced to use ``CsrfResponseMiddleware`` for these
 views to continue working).
@@ -364,7 +364,7 @@ exactly that.
 Caching
 =======
 
-If the ``csrf_token`` template tag is used by a template (or the ``get_token``
+If the :ttag:`csrf_token` template tag is used by a template (or the ``get_token``
 function is called some other way), ``CsrfViewMiddleware`` will add a cookie and
 a ``Vary: Cookie`` header to the response.  Similarly,
 ``CsrfResponseMiddleware`` will send the ``Vary: Cookie`` header if it inserted

docs/ref/databases.txt

@@ -256,7 +256,6 @@ Here's a sample configuration which uses a MySQL option file::
         }
     }
 
-
     # my.cnf
     [client]
     database = DATABASE_NAME

docs/ref/django-admin.txt

@@ -470,6 +470,11 @@ prompts.
 
 The alias for the database to reset.  By default resets all databases.
 
+Executes the equivalent of ``sqlreset`` for the given app name(s).
+
+The :djadminopt:`--noinput` option may be provided to suppress all user
+prompts.
+
 runfcgi [options]
 -----------------
 

docs/ref/settings.txt

@@ -190,7 +190,6 @@ end users) indicating the reason the request was rejected.  See
 :ref:`ref-contrib-csrf`.
 
 
-
 .. setting:: DATABASES
 
 DATABASES

docs/ref/templates/builtins.txt

@@ -51,6 +51,18 @@ comment
 
 Ignore everything between ``{% comment %}`` and ``{% endcomment %}``
 
+.. templatetag:: csrf_token
+
+csrf_token
+~~~~~~~~~~
+
+.. versionadded:: 1.1.2
+
+In the Django 1.1.X series, this is a no-op tag that returns an empty string for
+future compatibility purposes.  In Django 1.2 and later, it is used for CSRF
+protection, as described in the documentation for :ref:`Cross Site Request
+Forgeries <ref-contrib-csrf>`.
+
 .. templatetag:: cycle
 
 csrf_token

docs/releases/1.1.2.txt

@@ -0,0 +1,36 @@
+.. _releases-1.1.2:
+
+==============================================
+Django 1.1.2 release notes — UNDER DEVELOPMENT
+==============================================
+
+This page documents release notes for the as-yet-unreleased Django
+1.1.2. As such it is tentative and subject to change. It provides
+up-to-date information for those who are following the 1.1.X branch.
+
+This is the second "bugfix" release in the Django 1.1 series,
+improving the stability and performance of the Django 1.1 codebase.
+
+Django 1.1.2 maintains backwards compatibility with Django
+1.1.0, but contain a number of fixes and other
+improvements. Django 1.1.2 is a recommended upgrade for any
+development or deployment currently using or targeting Django 1.1.
+
+For full details on the new features, backwards incompatibilities, and
+deprecated features in the 1.1 branch, see the :ref:`releases-1.1`.
+
+One new feature
+---------------
+
+Ordinarily, a point release would not include new features, but in the
+case of Django 1.1.2, we have made an exception to this rule. Django
+1.2 (the next major release of Django) will contain a feature that
+will improve protection against Cross-Site Request Forgery (CSRF)
+attacks. This feature requires the use of a new :ttag:`csrf_token`
+template tag in all forms that Django renders.
+
+To make it easier to support both 1.1.X and 1.2.X versions of Django with
+the same templates, we have decided to introduce the :ttag:`csrf_token` template
+tag to the 1.1.X branch. In the 1.1.X branch, :ttag:`csrf_token` does nothing -
+it has no effect on templates or form processing. However, it means that the
+same template will work with Django 1.2.

docs/releases/1.2.txt

@@ -8,6 +8,11 @@ This page documents release notes for the as-yet-unreleased Django 1.2.  As such
 it is tentative and subject to change.  It provides up-to-date information for
 those who are following trunk.
 
+Django 1.2 includes a number of nifty `new features`_, lots of bug
+fixes, and an easy upgrade path from Django 1.1.
+
+.. _new features: `What's new in Django 1.2`_
+
 .. _backwards-incompatible-changes-1.2:
 
 Backwards-incompatible changes in 1.2
@@ -68,3 +73,37 @@ Features deprecated in 1.2
 ==========================
 
 None.
+
+What's new in Django 1.2
+========================
+
+CSRF support
+------------
+
+Django now has much improved protection against :ref:`Cross-Site
+Request Forgery (CSRF) attacks<ref-contrib-csrf>`. This type of attack
+occurs when a malicious Web site contains a link, a form button or
+some javascript that is intended to perform some action on your Web
+site, using the credentials of a logged-in user who visits the
+malicious site in their browser. A related type of attack, 'login
+CSRF', where an attacking site tricks a user's browser into logging
+into a site with someone else's credentials, is also covered.
+
+Email Backends
+--------------
+
+You can now :ref:`configure the way that Django sends email
+<topic-email-backends>`. Instead of using SMTP to send all email, you
+can now choose a configurable email backend to send messages. If your
+hosting provider uses a sandbox or some other non-SMTP technique for
+sending mail, you can now construct an email backend that will allow
+Django's standard :ref:`mail sending methods<topics-email>` to use
+those facilities.
+
+This also makes it easier to debug mail sending - Django ships with
+backend implementations that allow you to send email to a
+:ref:`file<topic-email-file-backend>`, to the
+:ref:`console<topic-email-console-backend>`, or to
+:ref:`memory<topic-email-memory-backend>` - you can even configure all
+email to be :ref:`thrown away<topic-email-console-backend>`.
+

docs/releases/index.txt

@@ -1,5 +1,6 @@
 .. _releases-index:
 
+=============
 Release notes
 =============
 
@@ -7,37 +8,60 @@ Release notes for the official Django releases. Each release note will tell you
 what's new in each version, and will also describe any backwards-incompatible
 changes made in that version.
 
+For those upgrading to a new version of Django, you will need to check
+all the backwards-incompatible changes and deprecated features for
+each 'final' release from the one after your current Django version,
+up to and including the new version.
+
+Final releases
+==============
+
+1.2 release
+-----------
 .. toctree::
    :maxdepth: 1
 
-   0.95
+   1.2
-   0.96
+
-   1.0-alpha-1
+1.1 release
-   1.0-alpha-2
+-----------
-   1.0-beta
+.. toctree::
-   1.0-beta-2
+   :maxdepth: 1
-   1.0
+
-   1.0.1
+   1.1.2
-   1.0.2
-   1.1-alpha-1
-   1.1-beta-1
-   1.1-rc-1
    1.1
 
-Upgrading
+1.0 release
-=========
+-----------
+.. toctree::
+   :maxdepth: 1
 
-For those upgrading to a new version of Django, you will need to check all the
+   1.0.2
-backwards-incompatible changes and deprecated features for each 'final' release
+   1.0.1
-from the one after your old version up to and including your new version.  The
+   1.0
-relevant sections of the release notes are linked below below for your
-convenience.
 
-For those following trunk, the tentative release notes for the next version to
+Pre-1.0 releases
-be released are also included at the bottom.  This is kept up to date with new
+----------------
-features and changes that you need to be aware of.
+.. toctree::
+   :maxdepth: 1
 
- * :ref:`backwards-incompatible-changes-1.1`
+   0.96
- * :ref:`deprecated-features-1.1`
+   0.95
- * :ref:`backwards-incompatible-changes-1.2`
+
- * :ref:`deprecated-features-1.2`
+Development releases
+====================
+
+These notes are retained for historical purposes. If you are upgrading
+between formal Django releases, you don't need to worry about these
+notes.
+
+.. toctree::
+   :maxdepth: 1
+
+   1.1-rc-1
+   1.1-beta-1
+   1.1-alpha-1
+   1.0-beta-2
+   1.0-beta
+   1.0-alpha-2
+   1.0-alpha-1

docs/topics/email.txt

@@ -421,6 +421,8 @@ want to specify it explicitly, put the following in your settings::
     still available in ``django.core.mail`` as an alias for the SMTP backend.
     New code should use :meth:`~django.core.mail.get_connection` instead.
 
+.. _topic-email-console-backend:
+
 Console backend
 ~~~~~~~~~~~~~~~
 
@@ -436,6 +438,8 @@ To specify this backend, put the following in your settings::
 This backend is not intended for use in production -- it is provided as a
 convenience that can be used during development.
 
+.. _topic-email-file-backend:
+
 File backend
 ~~~~~~~~~~~~
 
@@ -453,6 +457,8 @@ To specify this backend, put the following in your settings::
 This backend is not intended for use in production -- it is provided as a
 convenience that can be used during development.
 
+.. _topic-email-memory-backend:
+
 In-memory backend
 ~~~~~~~~~~~~~~~~~
 
@@ -469,6 +475,8 @@ To specify this backend, put the following in your settings::
 This backend is not intended for use in production -- it is provided as a
 convenience that can be used during development and testing.
 
+.. _topic-email-dummy-backend:
+
 Dummy backend
 ~~~~~~~~~~~~~
 

tests/regressiontests/backends/tests.py

@@ -18,6 +18,21 @@ class Callproc(unittest.TestCase):
             return True
         else:
             return True
+            
+class LongString(unittest.TestCase):
+
+    def test_long_string(self):
+        # If the backend is Oracle, test that we can save a text longer
+        # than 4000 chars and read it properly
+        if settings.DATABASE_ENGINE == 'oracle':
+            c = connection.cursor()
+            c.execute('CREATE TABLE ltext ("TEXT" NCLOB)')
+            long_str = ''.join([unicode(x) for x in xrange(4000)])
+            c.execute('INSERT INTO ltext VALUES (%s)',[long_str])
+            c.execute('SELECT text FROM ltext')
+            row = c.fetchone()
+            c.execute('DROP TABLE ltext')
+            self.assertEquals(long_str, row[0].read())
 
 class LongString(unittest.TestCase):