[gsoc2009-testing] Massive merge update to trunk. This is to prep for upload

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

django/contrib/admin/options.py

@@ -482,7 +482,7 @@ class ModelAdmin(BaseModelAdmin):
 
     def get_action(self, action):
         """
-        Return a given action from a parameter, which can either be a calable,
+        Return a given action from a parameter, which can either be a callable,
         or the name of a method on the ModelAdmin.  Return is a tuple of
         (callable, name, description).
         """

django/contrib/admin/templates/admin/delete_selected_confirmation.html

@@ -19,7 +19,7 @@
     {% endfor %}
     </ul>
 {% else %}
-    <p>{% blocktrans %}Are you sure you want to delete the selected {{ object_name }} objects? All of the following objects and it's related items will be deleted:{% endblocktrans %}</p>
+    <p>{% blocktrans %}Are you sure you want to delete the selected {{ object_name }} objects? All of the following objects and their related items will be deleted:{% endblocktrans %}</p>
     {% for deleteable_object in deletable_objects %}
         <ul>{{ deleteable_object|unordered_list }}</ul>
     {% endfor %}

django/contrib/gis/management/commands/inspectdb.py

@@ -131,7 +131,7 @@ class Command(InspectCommand):
                         if srid != 4326: extra_params['srid'] = srid
                     else:
                         try:
-                            field_type = connection.introspection.data_types_reverse[row[1]]
+                            field_type = connection.introspection.get_field_type(row[1], row)
                         except KeyError:
                             field_type = 'TextField'
                             comment_notes.append('This field type is a guess.')

django/core/management/commands/inspectdb.py

@@ -16,7 +16,8 @@ class Command(NoArgsCommand):
         from django.db import connection
         import keyword
         
-        table2model = lambda table_name: table_name.title().replace('_', '').replace(' ', '').replace('-', '')
+        table2model = lambda table_name: table_name.title()
+            .replace('_', '').replace(' ', '').replace('-', '').replace('*','_').replace(',','_')
 
         cursor = connection.cursor()
         yield "# This is an auto-generated Django model module."
@@ -73,7 +74,7 @@ class Command(NoArgsCommand):
                         extra_params['db_column'] = column_name
                 else:
                     try:
-                        field_type = connection.introspection.data_types_reverse[row[1]]
+                        field_type = connection.introspection.get_field_type(row[1], row)
                     except KeyError:
                         field_type = 'TextField'
                         comment_notes.append('This field type is a guess.')

django/db/backends/__init__.py

@@ -470,6 +470,14 @@ class BaseDatabaseIntrospection(object):
     def __init__(self, connection):
         self.connection = connection
 
+    def get_field_type(self, data_type, description):
+        """Hook for a database backend to use the cursor description to
+        match a Django field type to a database column.
+
+        For Oracle, the column data_type on its own is insufficient to
+        distinguish between a FloatField and IntegerField, for example."""
+        return self.data_types_reverse[data_type]
+
     def table_name_converter(self, name):
         """Apply a conversion to the name for the purposes of comparison.
 
@@ -560,4 +568,3 @@ class BaseDatabaseValidation(object):
     def validate_field(self, errors, opts, f):
         "By default, there is no backend-specific validation"
         pass
-

django/db/backends/oracle/base.py

@@ -36,6 +36,14 @@ DatabaseError = Database.DatabaseError
 IntegrityError = Database.IntegrityError
 
 
+# Check whether cx_Oracle was compiled with the WITH_UNICODE option.  This will
+# also be True in Python 3.0.
+if int(Database.version.split('.', 1)[0]) >= 5 and not hasattr(Database, 'UNICODE'):
+    convert_unicode = force_unicode
+else:
+    convert_unicode = smart_str
+
+
 class DatabaseFeatures(BaseDatabaseFeatures):
     empty_fetchmany_value = ()
     needs_datetime_string_cast = False
@@ -170,10 +178,10 @@ WHEN (new.%(col_name)s IS NULL)
         return "RETURNING %s INTO %%s", (InsertIdVar(),)
 
     def savepoint_create_sql(self, sid):
-        return "SAVEPOINT " + self.quote_name(sid)
+        return convert_unicode("SAVEPOINT " + self.quote_name(sid))
 
     def savepoint_rollback_sql(self, sid):
-        return "ROLLBACK TO SAVEPOINT " + self.quote_name(sid)
+        return convert_unicode("ROLLBACK TO SAVEPOINT " + self.quote_name(sid))
 
     def sql_flush(self, style, tables, sequences):
         # Return a list of 'TRUNCATE x;', 'TRUNCATE y;',
@@ -304,7 +312,7 @@ class DatabaseWrapper(BaseDatabaseWrapper):
     def _cursor(self):
         cursor = None
         if not self._valid_connection():
-            conn_string = self._connect_string()
+            conn_string = convert_unicode(self._connect_string())
             self.connection = Database.connect(conn_string, **self.settings_dict['DATABASE_OPTIONS'])
             cursor = FormatStylePlaceholderCursor(self.connection)
             # Set oracle date to ansi date format.  This only needs to execute
@@ -355,7 +363,8 @@ class OracleParam(object):
         if hasattr(param, 'bind_parameter'):
             self.smart_str = param.bind_parameter(cursor)
         else:
-            self.smart_str = smart_str(param, cursor.charset, strings_only)
+            self.smart_str = convert_unicode(param, cursor.charset,
+                                             strings_only)
         if hasattr(param, 'input_size'):
             # If parameter has `input_size` attribute, use that.
             self.input_size = param.input_size
@@ -423,7 +432,7 @@ class FormatStylePlaceholderCursor(object):
         # is being passed to SQL*Plus.
         if query.endswith(';') or query.endswith('/'):
             query = query[:-1]
-        query = smart_str(query, self.charset) % tuple(args)
+        query = convert_unicode(query % tuple(args), self.charset)
         self._guess_input_sizes([params])
         try:
             return self.cursor.execute(query, self._param_generator(params))
@@ -445,7 +454,7 @@ class FormatStylePlaceholderCursor(object):
         # is being passed to SQL*Plus.
         if query.endswith(';') or query.endswith('/'):
             query = query[:-1]
-        query = smart_str(query, self.charset) % tuple(args)
+        query = convert_unicode(query % tuple(args), self.charset)
         formatted = [self._format_params(i) for i in params]
         self._guess_input_sizes(formatted)
         try:

django/db/backends/oracle/introspection.py

@@ -26,6 +26,14 @@ class DatabaseIntrospection(BaseDatabaseIntrospection):
     except AttributeError:
         pass
 
+    def get_field_type(self, data_type, description):
+        # If it's a NUMBER with scale == 0, consider it an IntegerField
+        if data_type == cx_Oracle.NUMBER and description[5] == 0:
+            return 'IntegerField'
+        else:
+            return super(DatabaseIntrospection, self).get_field_type(
+                data_type, description)
+
     def get_table_list(self, cursor):
         "Returns a list of table names in the current database."
         cursor.execute("SELECT TABLE_NAME FROM USER_TABLES")

docs/conf.py

@@ -41,11 +41,11 @@ copyright = 'Django Software Foundation and contributors'
 # other places throughout the built documents.
 #
 # The short X.Y version.
-version = '1.0'
+version = '1.1'
 # The full version, including alpha/beta/rc tags.
 release = version
 # The next version to be released
-django_next_version = '1.1'
+django_next_version = '1.2'
 
 # There are two options for replacing |today|: either, you set today to some
 # non-false value, then it is used:

docs/howto/deployment/modpython.txt

@@ -264,7 +264,7 @@ the ``media`` subdirectory and any URL that ends with ``.jpg``, ``.gif`` or
 
 
 .. _lighttpd: http://www.lighttpd.net/
-.. _Nginx: http://wiki.codemongers.com/Main
+.. _Nginx: http://wiki.nginx.org/Main
 .. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
 .. _Apache: http://httpd.apache.org/
 .. _Cherokee: http://www.cherokee-project.com/

docs/howto/deployment/modwsgi.txt

@@ -98,7 +98,7 @@ file. All other URLs will be served using mod_wsgi::
     </Directory>
 
 .. _lighttpd: http://www.lighttpd.net/
-.. _Nginx: http://wiki.codemongers.com/Main
+.. _Nginx: http://wiki.nginx.org/Main
 .. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
 .. _Apache: http://httpd.apache.org/
 .. _Cherokee: http://www.cherokee-project.com/

docs/index.txt

@@ -189,7 +189,8 @@ The Django open-source project
     * **Community:**
       :ref:`How to get involved <internals-contributing>` |
       :ref:`The release process <internals-release-process>` |
-      :ref:`Team of committers <internals-committers>`
+      :ref:`Team of committers <internals-committers>` |
+      :ref:`The Django source code repository <internals-svn>`
 
     * **Design philosophies:**
       :ref:`Overview <misc-design-philosophies>`

docs/internals/svn.txt

@@ -0,0 +1,258 @@
+.. _internals-svn:
+
+=================================
+The Django source code repository
+=================================
+
+
+When deploying a Django application into a real production
+environment, you will almost always want to use `an official packaged
+release of Django`_. However, if you'd like to try out in-development
+code from an upcoming release or contribute to the development of
+Django, you'll need to obtain a checkout from Django's source code
+repository. This document covers the way the code repository is laid
+out and how to work with and find things in it.
+
+
+.. _an official packaged release of Django: http://www.djangoproject.com/download/
+
+
+High-level overview
+===================
+
+The Django source code repository uses `Subversion`_ to track changes
+to the code over time, so you'll need a copy of the Subversion client
+(a program called ``svn``) on your computer, and you'll want to
+familiarize yourself with the basics of how Subversion
+works. Subversion's web site offers downloads for various operating
+systems, and `a free online book`_ is available to help you get up to
+speed with using Subversion.
+
+The Django Subversion repository is located online at
+`code.djangoproject.com/svn <http://code.djangoproject.com/svn/>`_. `A
+friendly Web-based interface for browsing the code`_ is also
+available, though when using Subversion you'll always want to use the
+repository address instead. At the top level of the repository are two
+directories: ``django`` contains the full source code for all Django
+releases, while ``djangoproject.com`` contains the source code and
+templates for the `djangoproject.com <http://www.djangoproject.com/>`_
+web site. For trying out in-development Django code, or contributing
+to Django, you'll always want to check out code from some location in
+the ``django`` directory.
+
+Inside the ``django`` directory, Django's source code is organized
+into three areas:
+
+* ``branches`` contains branched copies of Django's code, which are
+  (or were) maintained for various purposes. Some branches exist to
+  provide a place to develop major or experimental new features
+  without affecting the rest of Django's code, while others serve to
+  provide bug fixes or support for older Django releases.
+
+* ``tags`` contains snapshots of Django's code at various important
+  points in its history; mostly these are the exact revisions from
+  which packaged Django releases were produced.
+
+* ``trunk`` contains the main in-development code which will become
+  the next packaged release of Django, and is where most development
+  activity is focused.
+
+
+.. _Subversion: http://subversion.tigris.org/
+.. _a free online book: http://svnbook.red-bean.com/
+.. _A friendly web-based interface for browsing the code: http://code.djangoproject.com/browser/
+
+
+Working with Django's trunk
+===========================
+
+If you'd like to try out the in-development code for the next release
+of Django, or if you'd like to contribute to Django by fixing bugs or
+developing new features, you'll want to get the code from trunk. You
+can get a complete copy of this code (a "Subversion checkout") by
+typing::
+
+    svn co http://code.djangoproject.com/svn/django/trunk/
+
+Note that this will get *all* of Django: in addition to the top-level
+``django`` module containing Python code, you'll also get a copy of
+Django's documentation, unit-test suite, packaging scripts and other
+miscellaneous bits. Django's code will be present in your checkout as
+a directory named ``django``.
+
+To try out the in-development trunk code with your own applications,
+simply place the directory containing your checkout on your Python
+import path. Then ``import`` statements which look for Django will find
+the ``django`` module within your checkout.
+
+If you're going to be working on Django's code (say, to fix a bug or
+develop a new feature), you can probably stop reading here and move
+over to :ref:`the documentation for contributing to Django
+<internals-contributing>`, which covers things like the preferred
+coding style and how to generate and submit a patch.
+
+
+Branches
+========
+
+Django uses branches for two main purposes:
+
+1. Development of major or experimental features, to keep them from
+   affecting progress on other work in trunk.
+
+2. Security and bug-fix support for older releases of Django, during
+   their support lifetimes.
+
+
+Feature-development branches
+----------------------------
+
+Feature-development branches tend by their nature to be
+temporary. Some produce successful features which are merged back into
+Django's trunk to become part of an official release, but others do
+not; in either case there comes a time when the branch is no longer
+being actively worked on by any developer. At this point the branch is
+considered closed.
+
+Unfortunately, Subversion has no standard way of indicating
+this. Generally, you can recognize a dead branch by viewing it through
+the web interface, which lists the date of the most recent change to
+the branch. Branches which have gone more than a month or two with no
+activity can usually be assumed to be closed. In the future, the
+layout of branches in the repository may be rearranged to make it
+easier to tell which branches are still active (e.g., by moving closed
+or abandoned branches into the ``django/branches/attic`` directory).
+
+For reference, the following are branches whose code eventually became
+part of Django itself, and so are no longer separately maintained:
+
+* ``boulder-oracle-sprint``: Added support for Oracle databases to
+  Django's object-relational mapper. This has been part of Django
+  since the 1.0 release.
+
+* ``gis``: Added support for geographic/spatial queries to Django's
+  object-relational mapper. This has been part of Django since the 1.0
+  release, as the bundled application ``django.contrib.gis``.
+
+* ``i18n``: Added :ref:`internationalization support <topics-i18n>` to
+  Django. This has been part of Django since the 0.90 release.
+
+* ``magic-removal``: A major refactoring of both the internals and
+  public APIs of Django's object-relational mapper. This has been part
+  of Django since the 0.95 release.
+
+* ``multi-auth``: A refactoring of :ref:`Django's bundled
+  authentication framework <topics-auth>` which added support for
+  :ref:`authentication backends <authentication-backends>`. This has
+  been part of Django since the 0.95 release.
+
+* ``new-admin``: A refactoring of :ref:`Django's bundled
+  administrative application <ref-contrib-admin>`. This became part of
+  Django as of the 0.91 release, but was superseded by another
+  refactoring (see next listing) prior to the Django 1.0 release.
+
+* ``newforms-admin``: The second refactoring of Django's bundled
+  administrative application. This became part of Django as of the 1.0
+  release, and is the basis of the current incarnation of
+  ``django.contrib.admin``.
+
+* ``queryset-refactor``: A refactoring of the internals of Django's
+  object-relational mapper. This became part of Django as of the 1.0
+  release.
+
+* ``unicode``: A refactoring of Django's internals to consistently use
+  Unicode-based strings in most places within Django and Django
+  applications. This became part of Django as of the 1.0 release.
+
+Additionally, the following branches are closed, but their code was
+never merged into Django and the features they aimed to implement
+were never finished:
+
+* ``full-history``
+
+* ``generic-auth``
+
+* ``multiple-db-support``
+
+* ``per-object-permissions``
+
+* ``schema-evolution``
+
+* ``schema-evolution-ng``
+
+* ``search-api``
+
+* ``sqlalchemy``
+
+
+Support and bugfix branches
+---------------------------
+
+In addition to fixing bugs in current trunk, the Django project
+provides official bug-fix support for the most recent released version
+of Django, and security support for the two most recently-released
+versions of Django. This support is provided via branches in which the
+necessary bug or security fixes are applied; the branches are then
+used as the basis for issuing bugfix or security releases.
+
+As of the Django 1.0 release, these branches can be found in the
+repository in the directory ``django/branches/releases``, and new branches
+will be created there approximately one month after each new Django
+release. For example, shortly after the release of Django 1.0, the
+branch ``django/branches/releases/1.0.X`` was created to receive bug
+fixes, and shortly after the release of Django 1.1 the branch
+``django/branches/releases/1.1.X`` will be created.
+
+Prior to the Django 1.0 release, these branches were maintaind within
+the top-level ``django/branches`` directory, and so the following
+branches exist there and provided support for older Django releases:
+
+* ``0.90-bugfixes``
+
+* ``0.91-bugfixes``
+
+* ``0.95-bugfixes``
+
+* ``0.96-bugfixes``
+
+Official support for those releases has expired, and so they no longer
+receive direct maintenance from the Django project. However, the
+branches continue to exist and interested community members have
+occasionally used them to provide unofficial support for old Django
+releases.
+
+
+Tags
+====
+
+The directory ``django/tags`` within the repository contains complete
+copies of the Django source code as it existed at various points in
+its history. These "tagged" copies of Django are *never* changed or
+updated; new tags may be added as needed, but once added they are
+considered read-only and serve as useful guides to Django's
+development history.
+
+Within ``django/tags/releases`` are copies of the code which formed each
+packaged release of Django, and each tag is named with the version
+number of the release to which it corresponds. So, for example,
+``django/tags/releases/1.1`` is a complete copy of the code which was
+packaged as the Django 1.1 release.
+
+Within ``django/tags/notable_moments`` are copies of the Django code from
+points which do not directly correspond to releases, but which are
+nonetheless important historical milestones for Django
+development. The current "notable moments" marked there are:
+
+* ``ipo``: Django's code as it existed at the moment Django was first
+  publicly announced in 2005.
+
+* ``pre-magic-removal``: The state of Django's code just before the
+  merging of the ``magic-removal`` branch (described above), which
+  significantly updated Django's object-relational mapper.
+
+* ``pre-newforms-admin``: The state of Django's code just before the
+  merging of the ``newforms-admin`` branch (see above), which
+  significantly updated Django's bundled administrative application.
+
+* Tags corresponding to each of the alpha, beta and release-candidate
+  packages in the run up to the Django 1.0 release.

docs/ref/contrib/formtools/form-wizard.txt

@@ -95,7 +95,7 @@ Creating a ``FormWizard`` class
 The next step is to create a :class:`~django.contrib.formtools.wizard.FormWizard`
 class, which should be a subclass of ``django.contrib.formtools.wizard.FormWizard``.
 
-As your :class:`~django.forms.forms.Form` classes, this
+As with your :class:`~django.forms.forms.Form` classes, this
 :class:`~django.contrib.formtools.wizard.FormWizard` class can live anywhere
 in your codebase, but convention is to put it in :file:`forms.py`.
 

docs/ref/databases.txt

@@ -476,6 +476,10 @@ version of the driver should **not** be used with Django;
 ``cx_Oracle`` 5.0.1 resolved this issue, so if you'd like to use a
 more recent ``cx_Oracle``, use version 5.0.1.
 
+``cx_Oracle`` 5.0.1 or greater can optionally be compiled with the
+``WITH_UNICODE`` environment variable.  This is recommended but not
+required.
+
 .. _`Oracle Database Server`: http://www.oracle.com/
 .. _`cx_Oracle`: http://cx-oracle.sourceforge.net/
 

docs/ref/forms/widgets.txt

@@ -24,6 +24,13 @@ commonly used groups of widgets:
 
     Password input: ``<input type='password' ...>``
 
+    Takes one optional argument:
+
+    .. attribute:: PasswordInput.render_value
+
+        Determines whether the widget will have a value filled in when the
+        form is re-displayed after a validation error (default is ``True``).
+
 .. class:: HiddenInput
 
     Hidden input: ``<input type='hidden' ...>``
@@ -88,6 +95,14 @@ commonly used groups of widgets:
 
     Checkbox: ``<input type='checkbox' ...>``
 
+    Takes one optional argument:
+
+    .. attribute:: CheckboxInput.check_test
+     
+        A callable that takes the value of the CheckBoxInput 
+        and returns ``True`` if the checkbox should be checked for
+        that value. 
+
 .. class:: Select
 
     Select widget: ``<select><option ...>...</select>``

tests/modeltests/expressions/models.py

@@ -117,6 +117,6 @@ FieldError: Joined field references are not permitted in this query
 >>> acme.save()
 Traceback (most recent call last):
 ...
-TypeError: int() argument must be a string or a number, not 'ExpressionNode'
+TypeError: int() argument must be a string or a number...
 
 """}

tests/regressiontests/backends/tests.py

@@ -1,7 +1,7 @@
 # -*- coding: utf-8 -*-
 # Unit and doctests for specific database backends.
 import unittest
-from django.db import connection
+from django.db import backend, connection
 from django.db.backends.signals import connection_created
 from django.conf import settings
 
@@ -11,9 +11,10 @@ class Callproc(unittest.TestCase):
         # If the backend is Oracle, test that we can call a standard
         # stored procedure through our cursor wrapper.
         if settings.DATABASE_ENGINE == 'oracle':
+            convert_unicode = backend.convert_unicode
             cursor = connection.cursor()
-            cursor.callproc('DBMS_SESSION.SET_IDENTIFIER',
+            cursor.callproc(convert_unicode('DBMS_SESSION.SET_IDENTIFIER'),
-                            ['_django_testing!',])
+                            [convert_unicode('_django_testing!'),])
             return True
         else:
             return True

tests/regressiontests/introspection/tests.py

@@ -76,7 +76,7 @@ class IntrospectionTests(TestCase):
     def test_get_table_description_types(self):
         cursor = connection.cursor()
         desc = connection.introspection.get_table_description(cursor, Reporter._meta.db_table)
-        self.assertEqual([datatype(r[1]) for r in desc],
+        self.assertEqual([datatype(r[1], r) for r in desc],
                           ['IntegerField', 'CharField', 'CharField', 'CharField'])
 
     # Regression test for #9991 - 'real' types in postgres
@@ -86,7 +86,7 @@ class IntrospectionTests(TestCase):
             cursor.execute("CREATE TABLE django_ixn_real_test_table (number REAL);")
             desc = connection.introspection.get_table_description(cursor, 'django_ixn_real_test_table')
             cursor.execute('DROP TABLE django_ixn_real_test_table;')
-            self.assertEqual(datatype(desc[0][1]), 'FloatField')
+            self.assertEqual(datatype(desc[0][1], desc[0]), 'FloatField')
 
     def test_get_relations(self):
         cursor = connection.cursor()
@@ -104,9 +104,10 @@ class IntrospectionTests(TestCase):
         indexes = connection.introspection.get_indexes(cursor, Article._meta.db_table)
         self.assertEqual(indexes['reporter_id'], {'unique': False, 'primary_key': False})
 
-def datatype(dbtype):
+
+def datatype(dbtype, description):
     """Helper to convert a data type into a string."""
-    dt = connection.introspection.data_types_reverse[dbtype]
+    dt = connection.introspection.get_field_type(dbtype, description)
     if type(dt) is tuple:
         return dt[0]
     else:

tests/regressiontests/queries/models.py

@@ -67,6 +67,9 @@ class Author(models.Model):
     num = models.IntegerField(unique=True)
     extra = models.ForeignKey(ExtraInfo)
 
+    class Meta:
+        ordering = ['name']
+
     def __unicode__(self):
         return self.name