Saturday, July 31, 2010

Re: moving to django 1.2.1

On Fri, Jul 30, 2010 at 8:14 PM, tiemonster <mark@tiemonster.info> wrote:
> I cover some of the new changes in Django 1.2 in this article:
> http://www.tiemonster.info/a/24005/
>
> Most of this information comes straight from the changelist. Others
> were things that the core developers must have assumed were common
> sense, but that I didn't think about when upgrading. If you run across
> anything that's not on the list, let me know and I'll update the
> article.

Hi Mark,

Since this conversation is happening in the context of a backwards
compatibility discussion, I want to provide some clarification to a
couple of elements of your blog post:

* Although we have introduced a new format for defining databases,
you aren't required to make any modifications in order to upgrade.
Old-style DATABASE_* settings will continue to work, as the release
notes describe [1].

[1] http://docs.djangoproject.com/en/dev/releases/1.2/#specifying-databases

* The problem with database caching isn't a backwards incompatible
problem; it's a bug with the database cache backend when used with
multiple database support. Since Django 1.1 didn't have support for
multiple databases, it's impossible for a Django 1.1 project to
experience a backwards incompatibility problem here. It is, however, a
bug in the a Django 1.2 feature. Ticket #13946 is tracking the
problem; it is on my radar, and I've just updated the triage state to
ensure that it doesn't get forgotten.

* If you have an existing project, the introduction of CSRF
protection in Django 1.2 shouldn't pose any obstacle to upgrading.
CSRF protection is turned on by default in new projects, but you need
to manually turn it on for existing projects (i.e., you need to add
the new middleware). If you don't add the new middleware, you don't
need to do anything in order to run your project under Django 1.2. The
only potential backwards incompatibility is if you have written custom
templates to override the default templates provided by Django's admin
-- but this is clearly highlighted in the release notes [2].

[2] http://docs.djangoproject.com/en/dev/releases/1.2/#csrf-protection

* Your comments about messages correctly points out that the changes
are completely transparent, and require no immediate action for
compatibility.

* I don't know where you've got your information on the changes to
the unit test system, but your comments are (to use a complex Latin
term) wrong :-) The example you point to [3] is exactly the same
example that existed in the docs for Django 1.1 [4] and Django 1.0
[5]. Django's Test Client has never had a dependency on either the
base unittest library or Django's own unittest extensions. Django 1.2
didn't introduce any significant changes to the test client. There
were some changes to the test runner -- the utility that sets up and
executes the test environment -- but again, those changes should be
completely transparent, and require no immediate change when
upgrading.

[3] http://docs.djangoproject.com/en/1.2/topics/testing/#example
[4] http://docs.djangoproject.com/en/1.1/topics/testing/#example
[5] http://docs.djangoproject.com/en/1.0/topics/testing/#example

* Your point about admin media is generally good advice, but isn't a
backwards compatibility problem. Yes, Django 1.2 has new admin media
files, and you will need to have a complete and correct checkout of
those files served by your media provider (CDN or otherwise).

As I said previously, we take backwards compatibility very seriously
as a project. Unless you have been tinkering with internals or relying
on behavior that is buggy, you should be able to upgrade from Django
1.1 to Django 1.2 without being required to make *any* changes to your
code. This has been my experience on all projects that I have updated.
If anyone can provide a documented example to the contrary, then that
is a bug that should be fixed, and may well be sufficient to trigger a
point release.

Note that I said *required* to make changes. There are many updates
that are worthwhile making that aren't required (and won't be until
Django 1.4 is released). Enabling CSRF protection is a good idea for
security sake. Updating database settings will enable new
architectural options. Switching to the new messaging framework allows
for anonymous users to receive messages, and also allows for cookie
based messaging. However, none of these modifications are required in
order to update to Django 1.2.

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

No comments:

Post a Comment