Upgrading to Django 1.3

Get Started. It's Free
or sign up with your email address
Rocket clouds
Upgrading to Django 1.3 by Mind Map: Upgrading to Django 1.3

1. better tear-down

2. Better time-zone support

3. Procedure

3.1. Use VirtualEnv + pip

3.1.1. VirtualEnv

3.1.1.1. install

3.1.1.2. activate

3.1.2. pip

3.1.2.1. freeze

3.1.2.1.1. deps

3.1.3. Strongly recommend to learn them

3.1.4. Douglas: Once you master VirtualEnv, also try VirtualEnvWrapper

3.2. Upgrade just Django

3.2.1. pip install --upgrade Django

3.2.2. ./manage.py test

3.2.3. Things to watch for (in general)

3.2.3.1. Accessing internals

3.2.3.1.1. such as

3.2.3.1.2. always document doing that

3.2.3.1.3. have tests for that code

3.2.3.2. Arbitrary arguments

3.2.3.2.1. such as

3.2.3.2.2. remember **kwargs

3.2.3.3. Monkeypatches

3.2.3.3.1. Prone to break

3.2.3.4. Deprecated APIs & backward incompatible changes

3.2.3.4.1. Check not getting warnings

3.3. Test

3.4. Upgrade 3rd party apps

3.4.1. Most already support 1.3

3.4.2. Upgrade them 1 by 1

3.4.3. Use pip

3.4.3.1. Declaratively configure dependencies & versions

3.5. Test

3.6. Deploy

3.6.1. command line

3.6.1.1. pip freeze > requirements.txt

3.6.1.2. pip install -r requirements.txt

3.6.2. to deal with inconsistency during upgrade

3.6.2.1. shutdown apache

3.6.2.2. if you have several servers, upgrade them 1 by 1

4. Deprecated & removed

4.1. AdminSite.root()

4.1.1. (r'^admin/', include(admin.site.urls)),

4.1.1.1. part of a large refactoring to make the admin more customizable

4.2. Auth backends that don't support anonymous

4.2.1. now they must

4.2.1.1. class MyAuthBackend(object):

4.2.1.1.1. support_object_permissions = False

4.2.1.1.2. support_anonymous_user = False

4.2.1.1.3. support_inactive_user = False

4.2.1.1.4. def authenticate(self, *kw): ...

4.3. more here:

4.3.1. http://django.me/deprecation

5. Backwards-incompatible changes

5.1. Usually due to

5.1.1. security fixes

5.1.2. data-loss bugs

5.2. Security fixes

5.2.1. Added CSRF validation for AJAX requests

5.2.1.1. prior to 1.3 they were exempted from CSRF validations

5.2.1.1.1. because it wa assumed that browsers won't allow cross-site scripting

5.2.1.1.2. but a Flash vulnerabilyty does expose this risk

5.2.1.1.3. $.ajaxSetup({ beforeSend: function(xhr, settings) {

5.2.1.1.4. http://django.me/csrf-ajax

5.2.1.2. Placed restrictions on filters in the admin

5.2.1.3. Stopped rendering passwords in PasswordInput

5.2.1.4. Stopped allowing password resets for inactive users

5.3. Data-loss bug: FileField file deleteion

5.3.1. https://gist.github.com/889692

5.3.1.1. but be careful

5.3.1.1.1. when cleaning orphan files

5.4. Optimizations

5.4.1. Manually-managed transactions need to be expllicitly closed

5.4.1.1. @transaction.commit_manually

5.4.2. New index on session table

5.4.2.1. python manage.py sqlindexes sessions

5.4.2.1.1. will make it faster

5.4.2.2. Anyway recommends not using db sessions

5.4.2.2.1. either memcached, or redis

5.5. The rest

5.5.1. Clearable FileField widget is default

5.5.2. No more PROFANITIES_LIST

5.5.2.1. in comments

5.5.2.1.1. never really worked in the 1st place

5.5.3. Localflavor corrections for Canada, Indonesia & the USA

5.5.4. FormSets can no longer take empty data

5.5.5. Initial SQL files no longer work in tests

5.5.5.1. use fixtures instead

6. The new hotness

6.1. Views

6.1.1. Improved template tags

6.1.1.1. {% with total=managers.count name=... %}

6.1.1.2. {% include "template.html" with total=... %}

6.1.1.3. {% load my_tag from my_tag_lib %}

6.1.1.4. {% load url from future %}

6.1.1.4.1. {% url "path.to.view" %}

6.1.1.4.2. {% url my_var arg kw=arg2 %}

6.1.2. Class-based generic views

6.1.2.1. Template view

6.1.2.1.1. class HelpView(TemplateView): template_name = "..."

6.1.2.1.2. url('..', HelpView.as_view())

6.1.2.2. Model views

6.1.2.2.1. DetailView

6.1.2.3. Base View class

6.1.2.4. All generic views

6.1.2.4.1. You need to extend them

6.1.2.5. Implementation

6.1.2.5.1. Each comprised of mix-ins

6.1.2.6. You can construct your own mix-ins

6.1.2.6.1. Replacing some mix-ins with our own

6.1.2.6.2. See example in docs of JSONDetailView

6.1.2.6.3. Read about Python's MRO

6.1.2.7. Should you use CBV's?

6.1.2.7.1. Wait till there's more experience with it

6.2. Model "on delete" options

6.2.1. (Jacob's favorite new feature)

6.2.2. in 1.2 deletes cascade

6.2.2.1. delete author will delete its books

6.2.3. author = models.ForeignKey(Person, on_delete=models.PROTECT)

6.2.3.1. will throw error when deleting author with books

6.2.4. on_delete=models.DO_NOTHING

6.2.4.1. leave it to the DB handle it

6.2.4.1.1. E.g., MySQL will throw integrity error

6.2.5. on_delete=models.SET_NULL

6.2.5.1. books Author will be set to null

6.2.6. on_delete=models.SET(get_dummy_person)

6.2.6.1. callback that will be called to set the author field of books

6.2.6.1.1. e.g., creates a person called: DELETED

6.2.7. on_delete=<your own callback>

6.2.7.1. def CASCADE_AND_PRINT(collector, field, sub_objs, using):

6.2.7.1.1. print "Deleting", sub_objs

6.2.7.1.2. return models.CASCADE(collector, field, sub_objs, using)

6.3. Testing

6.3.1. unittest2

6.3.1.1. will be part of 2.7

6.3.1.1.1. bundled in 1.3

6.3.1.2. vastly improved failure messages

6.3.1.2.1. shows smart diff of

6.3.1.3. skipping tests

6.3.1.3.1. @unittest.skipIf(platform.system() != 'Linux', "only works on linux")

6.3.1.3.2. skip

6.3.1.3.3. skipIf

6.3.1.3.4. skipUnless(condition, 'skipped if not condition')

6.3.1.3.5. skipIfDBFeature('supports_transactions')

6.3.1.3.6. skipUnlessDBFeature

6.3.1.4. assertRaises context manager

6.3.1.5. class & module level setUp/tearDown

6.3.1.6. usage

6.3.1.6.1. from django.test import TestCase

6.3.1.6.2. class MyTest(TestCase):

6.3.1.7. http://django.me/testing

6.3.2. RequestFactory

6.3.2.1. in 1.2

6.3.2.1.1. r = self.client.get('/some/view')

6.3.2.1.2. self.assertEqual(r.status_code, 200)

6.3.2.2. in 1,3

6.3.2.2.1. rf = django.test.client.RequestFactory()

6.3.2.2.2. request = rf.get('/some/view')

6.3.2.2.3. response = some_view(request)

6.3.2.2.4. self.assertEqual(response.status_code, 200)

6.3.2.3. directly invokes view, without the full stack

6.3.2.3.1. middleware &c

6.3.2.4. Jacob says he'll now write view tests like this

6.3.3. assertNumQueries

6.3.3.1. with self.assertNumQueries(2):

6.3.3.1.1. self.client.get('/some/view/')

6.4. Caching

6.4.1. Multiple caches

6.4.1.1. settings.CACHES

6.4.1.1.1. like databases

6.4.1.1.2. old syntax still work, but at some point you'll need to upgrade

6.4.1.2. syntax

6.4.1.2.1. CACHES = {

6.4.1.2.2. c1 = cache.get_cache('default')

6.4.1.2.3. c1.set(...)

6.4.1.3. changing version will invalidate all previous cache

6.4.1.3.1. there's a python API to change the version

6.4.2. versioning

6.4.3. site-wide prefixing

6.4.4. transformation

6.4.5. pylibmc support

6.4.5.1. new & much faster memcached

6.4.6. Suggestions:

6.4.6.1. switch to pylibmc

6.4.6.2. enable versioning

6.5. Static files

6.5.1. clears confusion

6.5.2. Definitions

6.5.2.1. "media"

6.5.2.1.1. files uploaded by users

6.5.2.2. "static"

6.5.2.2.1. static assets that are part of your site

6.5.2.3. "files"

6.5.2.3.1. either of the above

6.5.3. pluggable apps have their own static files

6.5.4. new contrib app

6.5.4.1. django.contrib.staticfiles

6.5.4.2. collects static files from multiple apps into a central location

6.5.4.2.1. & just that

6.5.5. usage

6.5.5.1. in developement

6.5.5.1.1. add to INSTALLED_APPS

6.5.5.1.2. put static files in

6.5.5.1.3. set STATIC_URL to "/static/"

6.5.5.2. in production

6.5.5.2.1. use dedicated media server

6.5.5.2.2. STATIC_ROOT = '/var/www/static/'

6.5.5.2.3. STATIC_URL = 'http://media.example.com/'

6.5.5.2.4. ./manage.py collectstatic

6.5.6. in templates

6.5.6.1. {% load static %}

6.5.6.2. ...

6.5.6.2.1. see docs

6.5.7. Suggestion

6.5.7.1. Switch if your current scheme makes you unhappy

6.5.8. There are more 3rd party apps with more features

6.5.8.1. compression

6.5.8.2. sprites

6.5.8.3. caching

6.5.8.4. &c

6.5.8.5. see in djangopackages.com

6.5.8.5.1. djangopackages.com > Grids > G > Asset-managers

6.5.8.6. django-storages

6.5.8.6.1. use S3 &c

6.6. Everything else

6.6.1. Logging

6.6.1.1. built-in support for Python logging

6.6.1.2. http://django.me/logging

6.6.1.2.1. Read docs - really good intro

6.6.2. TemplateResponse

6.6.2.1. similar to HttpResponse, yet Lazy

6.6.2.1.1. easier to do manipulations before rendering

6.6.2.2. http://django.me/TemplateResponse

6.6.3. django.shortcuts.render()

6.6.3.1. can use the requst processor

6.6.3.1.1. use it

6.6.4. Transactions as context managers

6.6.5. "Pretty" error emails

6.6.5.1. like the debug pages

6.6.6. "Current site" helper

6.6.6.1. get_current_site

6.6.7. HTTPOnly cookies

6.6.7.1. http://django.me/set_cookie

6.6.8. Context-aware simple tags

7. What's coming next

7.1. Planning for deprecation

7.1.1. to be removed in 1.4

7.1.1.1. Python 2.4 support

7.1.1.2. single-db support

7.1.1.3. User-based messages

7.1.1.3.1. user.message_set.create()

7.1.1.4. Legacy auth backends

7.1.1.4.1. supports_anonymous_user &c must be true

7.1.1.5. & more

7.1.2. to be removed in 1.5

7.1.2.1. Python 2.5 support (?)

7.1.2.1.1. 2.6 much faster

7.1.2.2. mod_python support

7.1.2.2.1. you can't event download it anymore

7.1.2.2.2. use mod_wsgi

7.1.2.3. Function based generic views

7.1.2.4. Old style url & ssi template tags

7.2. New features (speculations)

7.2.1. Basic schema migration support

7.2.1.1. bringing basic low level south api's

7.2.2. Refactor & formalization of "apps"

7.2.3. Improved ideas of what a "user" is

7.2.4. Better hooks for monitoring, debugging, metrics

7.2.5. Template compilation

7.2.5.1. speed improvements

7.2.6. Python 3 support

7.2.6.1. experimental probably

8. AMG POOP!