diff options
author | Kevin Kubasik <kevin@kubasik.net> | 2009-09-08 17:36:43 +0000 |
---|---|---|
committer | Kevin Kubasik <kevin@kubasik.net> | 2009-09-08 17:36:43 +0000 |
commit | 3de5792e13d777c2beedea11bcc308f6c9df4ff9 (patch) | |
tree | 88a433f78b5f77ab1964162594d25f6a59e7a5d9 | |
parent | e2d14c075a51eb1f0b832765df8723d82f0afac4 (diff) | |
parent | bb9cc01b132dbde2461191dbb1035eaae4885051 (diff) | |
download | django-soc2009/test-improvements.tar.gz |
[gsoc2009-testing] Massive merge update to trunk. This is to prep for uploadarchive/soc2009/test-improvementssoc2009/test-improvements
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/test-improvements@11480 bcc190cf-cafb-0310-a4f2-bffc1f526a37
-rw-r--r-- | django/contrib/admin/options.py | 2 | ||||
-rw-r--r-- | django/contrib/admin/templates/admin/delete_selected_confirmation.html | 4 | ||||
-rw-r--r-- | django/contrib/gis/management/commands/inspectdb.py | 2 | ||||
-rw-r--r-- | django/core/management/commands/inspectdb.py | 7 | ||||
-rw-r--r-- | django/db/backends/__init__.py | 9 | ||||
-rw-r--r-- | django/db/backends/oracle/base.py | 21 | ||||
-rw-r--r-- | django/db/backends/oracle/introspection.py | 8 | ||||
-rw-r--r-- | docs/conf.py | 4 | ||||
-rw-r--r-- | docs/howto/deployment/modpython.txt | 2 | ||||
-rw-r--r-- | docs/howto/deployment/modwsgi.txt | 2 | ||||
-rw-r--r-- | docs/index.txt | 3 | ||||
-rw-r--r-- | docs/internals/svn.txt | 258 | ||||
-rw-r--r-- | docs/ref/contrib/formtools/form-wizard.txt | 2 | ||||
-rw-r--r-- | docs/ref/databases.txt | 4 | ||||
-rw-r--r-- | docs/ref/forms/widgets.txt | 15 | ||||
-rw-r--r-- | tests/modeltests/expressions/models.py | 2 | ||||
-rw-r--r-- | tests/regressiontests/backends/tests.py | 7 | ||||
-rw-r--r-- | tests/regressiontests/introspection/tests.py | 9 | ||||
-rw-r--r-- | tests/regressiontests/queries/models.py | 3 |
19 files changed, 336 insertions, 28 deletions
diff --git a/django/contrib/admin/options.py b/django/contrib/admin/options.py index 31a28ccf0b..3144a22a2a 100644 --- a/django/contrib/admin/options.py +++ b/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). """ diff --git a/django/contrib/admin/templates/admin/delete_selected_confirmation.html b/django/contrib/admin/templates/admin/delete_selected_confirmation.html index a6258b94c0..5550b73e2e 100644 --- a/django/contrib/admin/templates/admin/delete_selected_confirmation.html +++ b/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 %} @@ -34,4 +34,4 @@ </div> </form> {% endif %} -{% endblock %}
\ No newline at end of file +{% endblock %} diff --git a/django/contrib/gis/management/commands/inspectdb.py b/django/contrib/gis/management/commands/inspectdb.py index d4fe210953..365bb24063 100644 --- a/django/contrib/gis/management/commands/inspectdb.py +++ b/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.') diff --git a/django/core/management/commands/inspectdb.py b/django/core/management/commands/inspectdb.py index f30a00b7b2..54203c532b 100644 --- a/django/core/management/commands/inspectdb.py +++ b/django/core/management/commands/inspectdb.py @@ -15,8 +15,9 @@ class Command(NoArgsCommand): def handle_inspection(self): 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.') diff --git a/django/db/backends/__init__.py b/django/db/backends/__init__.py index 579bf80aaf..9a1fe30925 100644 --- a/django/db/backends/__init__.py +++ b/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 - diff --git a/django/db/backends/oracle/base.py b/django/db/backends/oracle/base.py index 80558a0a68..c4155e2c9a 100644 --- a/django/db/backends/oracle/base.py +++ b/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: diff --git a/django/db/backends/oracle/introspection.py b/django/db/backends/oracle/introspection.py index 543e84a8f3..0b4f61a360 100644 --- a/django/db/backends/oracle/introspection.py +++ b/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") diff --git a/docs/conf.py b/docs/conf.py index 078c83a492..bdc1280c0b 100644 --- a/docs/conf.py +++ b/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: diff --git a/docs/howto/deployment/modpython.txt b/docs/howto/deployment/modpython.txt index 8b9a4d3696..50dadf9854 100644 --- a/docs/howto/deployment/modpython.txt +++ b/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/ diff --git a/docs/howto/deployment/modwsgi.txt b/docs/howto/deployment/modwsgi.txt index 8bfbfa74f4..12de53f53d 100644 --- a/docs/howto/deployment/modwsgi.txt +++ b/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/ diff --git a/docs/index.txt b/docs/index.txt index abe6416da3..03478f06a2 100644 --- a/docs/index.txt +++ b/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>` diff --git a/docs/internals/svn.txt b/docs/internals/svn.txt new file mode 100644 index 0000000000..7d010a7cfa --- /dev/null +++ b/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. diff --git a/docs/ref/contrib/formtools/form-wizard.txt b/docs/ref/contrib/formtools/form-wizard.txt index c81c24242a..98f0dbad42 100644 --- a/docs/ref/contrib/formtools/form-wizard.txt +++ b/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`. diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index 007a7079b7..fc58dbaf47 100644 --- a/docs/ref/databases.txt +++ b/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/ diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt index 9735c8181f..e2ba0d7889 100644 --- a/docs/ref/forms/widgets.txt +++ b/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>`` diff --git a/tests/modeltests/expressions/models.py b/tests/modeltests/expressions/models.py index d4de5ccee9..27daabad71 100644 --- a/tests/modeltests/expressions/models.py +++ b/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... """} diff --git a/tests/regressiontests/backends/tests.py b/tests/regressiontests/backends/tests.py index aff27369ad..628fabf04a 100644 --- a/tests/regressiontests/backends/tests.py +++ b/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', - ['_django_testing!',]) + cursor.callproc(convert_unicode('DBMS_SESSION.SET_IDENTIFIER'), + [convert_unicode('_django_testing!'),]) return True else: return True diff --git a/tests/regressiontests/introspection/tests.py b/tests/regressiontests/introspection/tests.py index 7072dc8e9e..1454e1e3e5 100644 --- a/tests/regressiontests/introspection/tests.py +++ b/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: diff --git a/tests/regressiontests/queries/models.py b/tests/regressiontests/queries/models.py index 0d28926149..cf21d5210b 100644 --- a/tests/regressiontests/queries/models.py +++ b/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 |