mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-07-04 01:39:20 +00:00
Code Issues 32 Releases Wiki Activity

gis: Merged revisions 4799-4809 via svnmerge.

Browse Source 
Last revision prior to 0.96 release.

git-svn-id: http://code.djangoproject.com/svn/django/branches/gis@4853 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jeremy Dunck 2007-03-29 16:58:58 +00:00
parent 2f15f72c89
commit 1a657ecf52
14 changed files with 124 additions and 192 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
django/__init__.py
View File

@ -1 +1 @@
VERSION = (0, 96, 'pre')
VERSION = (0, 96, None)

4
docs/add_ons.txt
View File

@ -51,8 +51,6 @@ See the `csrf documentation`_.
formtools
=========
**New in Django development version**
A set of high-level abstractions for Django forms (django.newforms).
django.contrib.formtools.preview
@ -142,8 +140,6 @@ See the `flatpages documentation`_.
localflavor
===========
**New in Django development version**
A collection of various Django snippets that are useful only for a particular
country or culture. For example, ``django.contrib.localflavor.usa.forms``
contains a ``USZipCodeField`` that you can use to validate U.S. zip codes.

34
docs/django-admin.txt
View File

@ -100,8 +100,6 @@ if you're ever curious to see the full list of defaults.
dumpdata [appname appname ...]
------------------------------
**New in Django development version**
Output to standard output all data in the database associated with the named
application(s).
@ -117,8 +115,6 @@ The output of ``dumpdata`` can be used as input for ``loaddata``.
flush
-----
**New in Django development version**
Return the database to the state it was in immediately after syncdb was
executed. This means that all data will be removed from the database, any
post-synchronization handlers will be re-executed, and the ``initial_data``
@ -165,18 +161,9 @@ needed.
``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection
only works in PostgreSQL and with certain types of MySQL tables.
install [appname appname ...]
-----------------------------
**Removed in Django development version**
Executes the equivalent of ``sqlall`` for the given appnames.
loaddata [fixture fixture ...]
------------------------------
**New in Django development version**
Searches for and loads the contents of the named fixture into the database.
A *Fixture* is a collection of files that contain the serialized contents of
@ -350,8 +337,6 @@ Prints the DROP TABLE SQL statements for the given appnames.
sqlcustom [appname appname ...]
-------------------------------
**New in Django development version**
Prints the custom SQL statements for the given appnames.
For each model in each specified app, this command looks for the file
@ -373,13 +358,6 @@ sqlindexes [appname appname ...]
Prints the CREATE INDEX SQL statements for the given appnames.
sqlinitialdata [appname appname ...]
--------------------------------------------
**Removed in Django development version**
This method has been renamed ``sqlcustom`` in the development version of Django.
sqlreset [appname appname ...]
--------------------------------------
@ -426,8 +404,6 @@ fixture data files.
test
----
**New in Django development version**
Discover and run tests for all installed models. See `Testing Django applications`_ for more information.
.. _testing django applications: ../testing/
@ -475,8 +451,6 @@ setting the Python path for you.
--format
--------
**New in Django development version**
Example usage::
django-admin.py dumpdata --format=xml
@ -493,8 +467,6 @@ options.
--indent
--------
**New in Django development version**
Example usage::
django-admin.py dumpdata --indent=4
@ -506,8 +478,6 @@ Pretty-printing will only be enabled if the indent option is provided.
--noinput
---------
**New in Django development version**
Inform django-admin that the user should NOT be prompted for any input. Useful
if the django-admin script will be executed as an unattended, automated
script.
@ -530,8 +500,6 @@ Example output::
--verbosity
-----------
**New in Django development version**
Example usage::
django-admin.py syncdb --verbosity=2
@ -543,8 +511,6 @@ and `2` is verbose output.
--adminmedia
------------
**New in Django development version**
Example usage::
django-admin.py manage.py --adminmedia=/tmp/new-admin-style/

7
docs/generic_views.txt
View File

@ -97,8 +97,7 @@ which is a dictionary of the parameters captured in the URL.
* ``extra_context``: A dictionary of values to add to the template
context. By default, this is an empty dictionary. If a value in the
dictionary is callable, the generic view will call it
just before rendering the template. (**This is new in the
Django development version.**)
just before rendering the template.
**Example:**
@ -752,10 +751,10 @@ If the results are paginated, the context will contain these extra variables:
* ``previous``: The previous page number, as an integer. This is 1-based.
* `last_on_page`: **New in Django development version** The number of the
* `last_on_page`: The number of the
last result on the current page. This is 1-based.
* `first_on_page`: **New in Django development version** The number of the
* `first_on_page`: The number of the
first result on the current page. This is 1-based.
* ``pages``: The total number of pages, as an integer.

2
docs/middleware.txt
View File

@ -104,8 +104,6 @@ Also removes the content from any response to a HEAD request and sets the
django.middleware.http.SetRemoteAddrFromForwardedFor
----------------------------------------------------
**New in Django development version**
Sets ``request.META['REMOTE_ADDR']`` based on
``request.META['HTTP_X_FORWARDED_FOR']``, if the latter is set. This is useful
if you're sitting behind a reverse proxy that causes each request's

11
docs/model-api.txt
View File

@ -362,9 +362,8 @@ Like a ``PositiveIntegerField``, but only allows values under a certain
containing only letters, numbers, underscores or hyphens. They're generally
used in URLs.
In the Django development version, you can specify ``maxlength``. If
``maxlength`` is not specified, Django will use a default length of 50. In
previous Django versions, there's no way to override the length of 50.
Like a CharField, you can specify ``maxlength``. If ``maxlength`` is
not specified, Django will use a default length of 50.
Implies ``db_index=True``.
@ -1457,8 +1456,8 @@ user searches for ``john lennon``, Django will do the equivalent of this SQL
WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')
AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')
**New in Django development version:** For faster and/or more restrictive
searches, prefix the field name with an operator:
For faster and/or more restrictive searches, prefix the field name
with an operator:
``^``
Matches the beginning of the field. For example, if ``search_fields`` is
@ -1754,8 +1753,6 @@ But this template code is good::
The ``permalink`` decorator
~~~~~~~~~~~~~~~~~~~~~~~~~~~
**New in Django development version.**
The problem with the way we wrote ``get_absolute_url()`` above is that it
slightly violates the DRY principle: the URL for this object is defined both
in the URLConf file and in the model.

7
docs/newforms.txt
View File

@ -9,9 +9,10 @@ framework. This document explains how to use this new library.
Migration plan
==============
``django.newforms`` currently is only available in the Django development version
-- i.e., it's not available in the Django 0.95 release. For the next Django
release, our plan is to do the following:
``django.newforms`` currently is only available in Django beginning
with the 0.96 release. the Django development version -- i.e., it's
not available in the Django 0.95 release. For the next Django release,
our plan is to do the following:
* As of revision [4208], we've copied the current ``django.forms`` to
``django.oldforms``. This allows you to upgrade your code *now* rather

214
docs/release_notes_0.96.txt
View File

@ -17,6 +17,113 @@ next official release; then you'll be able to upgrade in one step
instead of needing to make incremental changes to keep up with the
development version of Django.
Backwards-incompatible changes
==============================
The following changes may require you to update your code when you switch from
0.95 to 0.96:
``MySQLdb`` version requirement
-------------------------------
Due to a bug in older versions of the ``MySQLdb`` Python module (which
Django uses to connect to MySQL databases), Django's MySQL backend now
requires version 1.2.1p2 or higher of `MySQLdb`, and will raise
exceptions if you attempt to use an older version.
If you're currently unable to upgrade your copy of ``MySQLdb`` to meet
this requirement, a separate, backwards-compatible backend, called
"mysql_old", has been added to Django. To use this backend, change
the ``DATABASE_ENGINE`` setting in your Django settings file from
this::
DATABASE_ENGINE = "mysql"
to this::
DATABASE_ENGINE = "mysql_old"
However, we strongly encourage MySQL users to upgrade to a more recent
version of `MySQLdb` as soon as possible, The "mysql_old" backend is
provided only to ease this transition, and is considered deprecated;
aside from any necessary security fixes, it will not be actively
maintained, and it will be removed in a future release of Django.
Also, note that some features, like the new ``DATABASE_OPTIONS``
setting (see the `databases documentation`_ for details), are only
available on the "mysql" backend, and will not be made available for
"mysql_old".
.. _databases documentation: ../databases/
Database constraint names changed
---------------------------------
The format of the constraint names Django generates for foreign key
references have changed slightly. These names are generally only used
when it is not possible to put the reference directly on the affected
column, so they is not always visible.
The effect of this change is that running ``manage.py reset`` and
similar commands against an existing database may generate SQL with
the new form of constraint name, while the database itself contains
constraints named in the old form; this will cause the database server
to raise an error message about modifying non-existent constraints.
If you need to work around this, there are two methods available:
1. Redirect the output of ``manage.py`` to a file, and edit the
generated SQL to use the correct constraint names before
executing it.
2. Examine the output of ``manage.py sqlall`` to see the new-style
constraint names, and use that as a guide to rename existing
constraints in your database.
Name changes in ``manage.py``
-----------------------------
A few of the options to ``manage.py`` have changed with the addition of fixture
support:
* There are new ``dumpdata`` and ``loaddata`` commands which, as
you might expect, will dump and load data to/from the
database. These commands can operate against any of Django's
supported serialization formats.
* The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to
emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for
other custom SQL -- views, stored procedures, etc.).
* The vestigial ``install`` command has been removed. Use ``syncdb``.
Backslash escaping changed
--------------------------
The Django database API now escapes backslashes given as query parameters. If
you have any database API code that matches backslashes, and it was working before
(despite the lack of escaping), you'll have to change your code to "unescape" the
slashes one level.
For example, this used to work::
# Find text containing a single backslash
MyModel.objects.filter(text__contains='\\\\')
The above is now incorrect, and should be rewritten as::
# Find text containing a single backslash
MyModel.objects.filter(text__contains='\\')
Removed ENABLE_PSYCO setting
----------------------------
The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes
``ENABLE_PSYCO`` it will have no effect; to use Psyco_, we recommend
writing a middleware class to activate it.
.. _psyco: http://psyco.sourceforge.net/
What's new in 0.96?
===================
@ -130,113 +237,6 @@ A small change, but a very nice one: dedicated views for adding and
updating users have been added to the admin interface, so you no
longer need to worry about working with hashed passwords in the admin.
Backwards-incompatible changes
==============================
The following changes may require you to update your code when you switch from
0.95 to 0.96:
`MySQLdb` version requirement
-----------------------------
Due to a bug in older versions of the `MySQLdb` Python module (which
Django uses to connect to MySQL databases), Django's MySQL backend now
requires version 1.2.1p2 or higher of `MySQLdb`, and will raise
exceptions if you attempt to use an older version.
If you're currently unable to upgrade your copy of `MySQLdb` to meet
this requirement, a separate, backwards-compatible backend, called
"mysql_old", has been added to Django. To use this backend, change
the ``DATABASE_ENGINE`` setting in your Django settings file from
this::
DATABASE_ENGINE = "mysql"
to this::
DATABASE_ENGINE = "mysql_old"
However, we strongly encourage MySQL users to upgrade to a more recent
version of `MySQLdb` as soon as possible, The "mysql_old" backend is
provided only to ease this transition, and is considered deprecated;
aside from any necessary security fixes, it will not be actively
maintained, and it will be removed in a future release of Django.
Also, note that some features, like the new ``DATABASE_OPTIONS``
setting (see the `databases documentation`_ for details), are only
available on the "mysql" backend, and will not be made available for
"mysql_old".
.. _databases: ../databases/
Database constraint names changed
---------------------------------
The format of the constraint names Django generates for foreign key
references have changed slightly. These names are generally only used
when it is not possible to put the reference directly on the affected
column, so they is not always visible.
The effect of this change is that running ``manage.py reset`` and
similar commands against an existing database may generate SQL with
the new form of constraint name, while the database itself contains
constraints named in the old form; this will cause the database server
to raise an error message about modifying non-existent constraints.
If you need to work around this, there are two methods available:
1. Redirect the output of ``manage.py`` to a file, and edit the
generated SQL to use the correct constraint names before
executing it.
2. Examine the output of ``manage.py sqlall`` to see the new-style
constraint names, and use that as a guide to rename existing
constraints in your database.
Names changes in ``manage.py``
------------------------------
A few of the options to ``manage.py`` have changed with the addition of fixture
support:
* There are new ``dumpdata`` and ``loaddata`` commands which, as
you might expect, will dump and load data to/from the
database. These commands can operate against any of Django's
supported serialization formats.
* The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to
emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for
other custom SQL -- views, stored procedures, etc.).
* The vestigial ``install`` command has been removed. Use ``syncdb``.
Backslash escaping changed
--------------------------
The Django database API now escapes backslashes given as query parameters. If
you have any database API code that matches backslashes, and it was working before
(despite the lack of escaping), you'll have to change your code to "unescape" the
slashes one level.
For example, this used to work::
# Find text containing a single backslash
MyModel.objects.filter(text__contains='\\\\')
The above is now incorrect, and should be rewritten as::
# Find text containing a single backslash
MyModel.objects.filter(text__contains='\\')
Removed ENABLE_PSYCO setting
----------------------------
The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes
``ENABLE_PSYCO`` it will have no effect; to use Psyco, we recommend
writing a middleware class to activate it.
.. _psyco: http://psyco.sourceforge.net/
Thanks
======

1
docs/request_response.txt
View File

@ -384,7 +384,6 @@ Methods
Deletes the cookie with the given key. Fails silently if the key doesn't
exist.
The ``path`` and ``domain`` arguments are new in the Django development version.
Due to the way cookies work, ``path`` and ``domain`` should be the same
values you used in ``set_cookie()`` -- otherwise the cookie may not be deleted.

2
docs/sessions.txt
View File

@ -265,8 +265,6 @@ The name of the cookie to use for sessions. This can be whatever you want.
SESSION_COOKIE_SECURE
---------------------
**New in Django development version**
Default: ``False``
Whether to use a secure cookie for the session cookie. If this is set to

8
docs/settings.txt
View File

@ -429,8 +429,6 @@ trailing space.
FIXTURE_DIRS
-------------
**New in Django development version**
Default: ``()`` (Empty tuple)
List of locations of the fixture data files, in search order. Note that
@ -716,8 +714,6 @@ See the `session docs`_.
SESSION_COOKIE_SECURE
---------------------
**New in Django development version**
Default: ``False``
Whether to use a secure cookie for the session cookie. If this is set to
@ -812,8 +808,6 @@ misspelled) variables. See `How invalid variables are handled`_.
TEST_RUNNER
-----------
**New in Django development version**
Default: ``'django.test.simple.run_tests'``
The name of the method to use for starting the test suite. See
@ -824,8 +818,6 @@ The name of the method to use for starting the test suite. See
TEST_DATABASE_NAME
------------------
**New in Django development version**
Default: ``None``
The name of database to use when running the test suite. If a value of

18
docs/templates.txt
View File

@ -112,8 +112,6 @@ know how to write Python code.
Comments
========
**New in Django development version**
To comment-out part of a template, use the comment syntax: ``{# #}``.
For example, this template would render as ``'hello'``::
@ -253,8 +251,8 @@ Here are some tips for working with inheritance:
if you want to add to the contents of a parent block instead of
completely overriding it.
* **New in Django development version:** For extra readability, you can
optionally give a *name* to your ``{% endblock %}`` tag. For example::
* For extra readability, you can optionally give a *name* to your
``{% endblock %}`` tag. For example::
{% block content %}
...
@ -548,9 +546,9 @@ The 'ifchanged' block tag is used within a loop. It has two possible uses.
<a href="{{ date|date:"M/d"|lower }}/">{{ date|date:"j" }}</a>
{% endfor %}
2. **New in Django development version.** If given a variable, check whether that
variable has changed. For example, the following shows the date every time it
changes, but only shows the hour if both the hour and the date has changed::
2. If given a variable, check whether that variable has changed. For
example, the following shows the date every time it changes, but
only shows the hour if both the hour and the date has changed::
{% for date in days %}
{% ifchanged date.date %} {{ date.date }} {% endifchanged %}
@ -828,13 +826,9 @@ The argument tells which template bit to output:
``closecomment`` ``#}``
================== =======
Note: ``opencomment`` and ``closecomment`` are new in the Django development version.
url
~~~
**New in Django development version**
**Note that the syntax for this tag may change in the future, as we make it more robust.**
Returns an absolute URL (i.e., a URL without the domain name) matching a given
@ -976,8 +970,6 @@ place -- but only if there's a decimal part to be displayed. For example:
* ``36.15`` gets converted to ``36.2``
* ``36`` gets converted to ``36``
**New in Django development version**
If used with a numeric integer argument, ``floatformat`` rounds a number to that
many decimal places. For example:

2
docs/testing.txt
View File

@ -2,8 +2,6 @@
Testing Django applications
===========================
**New in Django development version**.
Automated testing is an extremely useful weapon in the bug-killing arsenal
of the modern developer. When initially writing code, a test suite can be
used to validate that code behaves as expected. When refactoring or

4
docs/url_dispatch.txt
View File

@ -400,8 +400,6 @@ to pass metadata and options to views.
Passing extra options to ``include()``
--------------------------------------
**New in Django development version.**
Similarly, you can pass extra options to ``include()``. When you pass extra
options to ``include()``, *each* line in the included URLconf will be passed
the extra options.
@ -442,8 +440,6 @@ every view in the the included URLconf accepts the extra options you're passing.
Passing callable objects instead of strings
===========================================
**New in Django development version.**
Some developers find it more natural to pass the actual Python function object
rather than a string containing the path to its module. This alternative is
supported -- you can pass any callable object as the view.