From 34b4d1ef431eed1ef4368958516dc7659108fde1 Mon Sep 17 00:00:00 2001 From: Malcolm Tredinnick Date: Sat, 8 Aug 2009 02:56:19 +0000 Subject: [PATCH 01/12] Bumped the version number in the docs to reflect Djagno 1.1 is released. This changes a bunch of "new in development version" annotations to say "new in Django 1.1" for example. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11413 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/conf.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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: From e6e96d871dd76a862451fd081d77d2ed0f09eb45 Mon Sep 17 00:00:00 2001 From: Karen Tracey Date: Sun, 9 Aug 2009 15:44:09 +0000 Subject: [PATCH 02/12] Fix the expressions modeltest to work on Pythons earlier than 2.5. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11423 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- tests/modeltests/expressions/models.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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... """} From c8517025af631ef905b7e3c7169383c4c8650233 Mon Sep 17 00:00:00 2001 From: Karen Tracey Date: Thu, 13 Aug 2009 16:53:19 +0000 Subject: [PATCH 03/12] Fixed #11573: Updated Nginx url. Thanks bryanveloso. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11442 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/howto/deployment/modpython.txt | 2 +- docs/howto/deployment/modwsgi.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) 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:: .. _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/ From b82ad10f9d20643e8c1372210cf5c279402789cc Mon Sep 17 00:00:00 2001 From: Karen Tracey Date: Thu, 13 Aug 2009 16:59:59 +0000 Subject: [PATCH 04/12] Fixed #11508: Adding missing word to form wizard doc. Thanks thepointer and timo. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11444 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/ref/contrib/formtools/form-wizard.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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`. From ab6d6896c47e80307af8e2ed676d75a238861e1d Mon Sep 17 00:00:00 2001 From: Karen Tracey Date: Thu, 13 Aug 2009 17:04:42 +0000 Subject: [PATCH 05/12] Fixed #11471: Fixed typo in a comment in admin options.py. Thanks adamv. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11446 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- django/contrib/admin/options.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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). """ From eaf1f7d6e3a0cb700895e9986a246c03243c65b7 Mon Sep 17 00:00:00 2001 From: Karen Tracey Date: Thu, 13 Aug 2009 17:16:29 +0000 Subject: [PATCH 06/12] Fixed #11534: Improved wording for admin delete confirmation. Thanks hanksims and others who reported this. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11447 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- .../admin/templates/admin/delete_selected_confirmation.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 %} {% else %} -

{% 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 %}

+

{% 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 %}

{% for deleteable_object in deletable_objects %}
    {{ deleteable_object|unordered_list }}
{% endfor %} @@ -34,4 +34,4 @@ {% endif %} -{% endblock %} \ No newline at end of file +{% endblock %} From 5eda3a16dfa6b40907a9edfad4ed9e3d3fdaeb1c Mon Sep 17 00:00:00 2001 From: James Bennett Date: Mon, 17 Aug 2009 10:23:43 +0000 Subject: [PATCH 07/12] Add new documentation covering the layout of the Django SVN repository. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11466 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/index.txt | 3 +- docs/internals/svn.txt | 258 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 260 insertions(+), 1 deletion(-) create mode 100644 docs/internals/svn.txt diff --git a/docs/index.txt b/docs/index.txt index 86105372c4..d03f90c117 100644 --- a/docs/index.txt +++ b/docs/index.txt @@ -187,7 +187,8 @@ The Django open-source project * **Community:** :ref:`How to get involved ` | :ref:`The release process ` | - :ref:`Team of committers ` + :ref:`Team of committers ` | + :ref:`The Django source code repository ` * **Design philosophies:** :ref:`Overview ` diff --git a/docs/internals/svn.txt b/docs/internals/svn.txt new file mode 100644 index 0000000000..a3935e3819 --- /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 `_. `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 for the `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 +`, 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 ` 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 ` which added support for + :ref:`authentication backends `. This has + been part of Django since the 0.95 release. + +* ``new-admin``: A refactoring of :ref:`Django's bundled + administrative application `. 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. From 150ef1adeeba3f46e0cf426c42ab1fc71a07d80b Mon Sep 17 00:00:00 2001 From: James Bennett Date: Mon, 17 Aug 2009 10:51:35 +0000 Subject: [PATCH 08/12] Correct a typo and a reST formatting problem in [11466]. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11467 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/internals/svn.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/internals/svn.txt b/docs/internals/svn.txt index a3935e3819..7d010a7cfa 100644 --- a/docs/internals/svn.txt +++ b/docs/internals/svn.txt @@ -35,10 +35,10 @@ 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 for the `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. +templates for the `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: From e0ce9d76e1a4b74db93c106f8267339af5f9d73e Mon Sep 17 00:00:00 2001 From: Matt Boersma Date: Thu, 20 Aug 2009 16:05:25 +0000 Subject: [PATCH 09/12] Fixed an assumed ordering in the queries regression tests by making it explicit. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11474 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- tests/regressiontests/queries/models.py | 3 +++ 1 file changed, 3 insertions(+) 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 From e263cc0dc53577d525aad0546fc1bd5939dc2e0b Mon Sep 17 00:00:00 2001 From: Matt Boersma Date: Fri, 21 Aug 2009 21:42:39 +0000 Subject: [PATCH 10/12] Fixed #11049: introspection on Oracle now identifies IntegerFields correctly. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11475 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- django/contrib/gis/management/commands/inspectdb.py | 2 +- django/core/management/commands/inspectdb.py | 2 +- django/db/backends/__init__.py | 9 ++++++++- django/db/backends/oracle/introspection.py | 8 ++++++++ tests/regressiontests/introspection/tests.py | 9 +++++---- 5 files changed, 23 insertions(+), 7 deletions(-) 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..fbe539274e 100644 --- a/django/core/management/commands/inspectdb.py +++ b/django/core/management/commands/inspectdb.py @@ -73,7 +73,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/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/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: From dcf3be7a621f011a918453527406216a738acf68 Mon Sep 17 00:00:00 2001 From: Ian Kelly Date: Mon, 24 Aug 2009 15:45:48 +0000 Subject: [PATCH 11/12] Fixed #10566: Added support for cx_Oracle compiled with the WITH_UNICODE flag. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11477 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- django/db/backends/oracle/base.py | 21 +++++++++++++++------ docs/ref/databases.txt | 4 ++++ tests/regressiontests/backends/tests.py | 7 ++++--- 3 files changed, 23 insertions(+), 9 deletions(-) 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/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/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 From bb9cc01b132dbde2461191dbb1035eaae4885051 Mon Sep 17 00:00:00 2001 From: Karen Tracey Date: Sat, 29 Aug 2009 12:40:47 +0000 Subject: [PATCH 12/12] Fixed #6674: Documented a couple of widget arguments. Thanks timo. git-svn-id: http://code.djangoproject.com/svn/django/trunk@11478 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/ref/forms/widgets.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) 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: ```` + 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: ```` @@ -88,6 +95,14 @@ commonly used groups of widgets: 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: ````