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-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.