1
0
mirror of https://github.com/django/django.git synced 2025-07-04 01:39:20 +00:00

[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
This commit is contained in:
Kevin Kubasik 2009-09-08 17:36:43 +00:00
commit 3de5792e13
19 changed files with 336 additions and 28 deletions

View File

@ -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).
"""

View File

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

View File

@ -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.')

View File

@ -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.')

View File

@ -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

View File

@ -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:

View File

@ -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")

View File

@ -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:

View File

@ -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/

View File

@ -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/

View File

@ -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>`

258
docs/internals/svn.txt Normal file
View File

@ -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.

View File

@ -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`.

View File

@ -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/

View File

@ -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>``

View File

@ -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...
"""}

View File

@ -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

View File

@ -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:

View File

@ -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