Re: moving to django 1.2.1

Thank you so much for the valuable feedback regarding my post. I value
peer review, and take it very seriously. I've updated the article to
attempt to address your concerns. Please review it at your convenience
to ensure that your concerns are addressed appropriately.

http://www.tiemonster.info/a/24005/

Regards,
Mark Cahill

On Jul 31, 11:49 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Fri, Jul 30, 2010 at 8:14 PM, tiemonster <m...@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.