Migrating to 1.4

[Dan Fairs]

Hi,

Since most people only ever report bugs, I wanted to report success in the initial migration of a relatively large project (~35k lines of Python application code, excluding comments and migrations, with ~43k lines of test code over ~2.5k tests) to Django 1.4 rc1. The production environment is running Django 1.3.1. Both are using Python 2.7.2 and MySQL.

Relatively few changes were necessary. 

There were a couple of bumps on the way (bugs #17879 and #17891) which were fixed quickly. 

I also had to spend some time updating some of our code which customises bits of Django that don't look like they were meant to be customised. We have custom logic for computing template lookup paths that depends on the request (skinning, basically), which doesn't 'fit' into a custom template loader. 'Normal' views are handled by way of an overridden get_template_names() in a base view - all our views are class-based, but:

- We have a custom template tag that derives from ExtendsNode, and overrides get_parent

- We have a custom Library implementation that overrides inclusion_tag(), which knows

  about our template lookup logic; it broke because the signature for generic_tag_compiler

  changed. 

Both of these were fixed by using the new implementations from Django itself, and re-applying our small changes.

Should I raise backwards-incompatibility tickets for these? They're pretty obscure, and I can't imagine many people are doing them. I raised #17891 because the code involved a clear extension point.

At this point, everything else seems to have 'just worked' - including some moderately scary model generation code - and I was finally able to remove our `backports` app containing signed cookies and cookie-based sessions, and our build-time patch for select_for_update(). Next up is checking that there aren't any significant performance regressions.

Thanks, everyone!

Cheers,

Dan

--
Dan Fairs | dan....@gmail.com | www.fezconsulting.com

[Dustin Farris]

Wow, that's a big project!  Thanks for sharing your success story. :)

[Philippe Raoult]

Thanks for the heads-up. My 50k python lines project is still running
1.2.7 + #12823. For some reason this patch can't seem to be commited,
despite being a potiential data-loss. I'm still worrying about
migrating to 1.3.1!

Best regards,
Philippe

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

[Adrian Holovaty]

On Wed, Mar 14, 2012 at 10:22 AM, Dan Fairs <dan....@gmail.com> wrote:
> - We have a custom template tag that derives from ExtendsNode, and overrides
> get_parent
> - We have a custom Library implementation that overrides inclusion_tag(),
> which knows
>   about our template lookup logic; it broke because the signature for
> generic_tag_compiler
>   changed.
>
> Both of these were fixed by using the new implementations from Django
> itself, and re-applying our small changes.
>
> Should I raise backwards-incompatibility tickets for these? They're pretty
> obscure, and I can't imagine many people are doing them. I raised #17891
> because the code involved a clear extension point.

Thanks for sharing this story, Dan! It's great to hear. Let us know
about the performance differences (if any), too.

Regarding backwards-incompatibility on those undocumented things,
write up a patch for the release notes if you'd like. Specifically,
add it to the "Backwards incompatible changes in 1.4" section in
docs/releases/1.4.txt.

Adrian

[Dan Fairs]

Hi,

Both of these were fixed by using the new implementations from Django

itself, and re-applying our small changes.

Should I raise backwards-incompatibility tickets for these? They're pretty

obscure, and I can't imagine many people are doing them. I raised #17891

because the code involved a clear extension point.

Thanks for sharing this story, Dan! It's great to hear. Let us know
about the performance differences (if any), too.

Well, we're finally getting into the performance side of things now!

The first big regression for us was that our test suite took 20% longer to run. I traced this down to the new default password hasher. This is clearly by design - and we'll just use the PASSWORD_HASHERS setting to use a faster (and much less secure) hasher for test runs.

Fortunately our app uses an external authentication service for most of its users, so this won't affect us in production - but for those running sites with high signup rates, this could be a surprise. Is that worth a mention in the release notes?

[Ryan Kaskel]

My project has about half as many tests but boy did the run slowly on my Django 1.4 upgrade branch.

On Monday, 16 April 2012 15:33:31 UTC+1, Dan Fairs wrote:

The first big regression for us was that our test suite took 20% longer to run. I traced this down to the new default password hasher. This is clearly by design - and we'll just use the PASSWORD_HASHERS setting to use a faster (and much less secure) hasher for test runs.

... and now I know why! After changing the setting, my tests run just a tad slower on 1.4. You've cleared the path for our upgrade which will happen in the next few weeks or so. Thanks!

Best,

Ryan

[Mikhail Korobov]

Thanks man!

PASSWORD_HASHERS = ('django.contrib.auth.hashers.MD5PasswordHasher',)

in test_settings.py made tests of our project 2x faster (I was not upgrading from 1.3).

понедельник, 16 апреля 2012 г., 20:33:31 UTC+6 пользователь Dan Fairs написал:

[Carl Meyer]

Since it seems that the additional test-suite runtime from the new
default password hasher is enough to be a blocker for migrations to 1.4
in some cases, I've opened a ticket for documenting this workaround:
https://code.djangoproject.com/ticket/18157

Carl

[Anssi Kääriäinen]

It might make sense to do this change in Django's test_sqlite
settings, too. The speed difference is noticeable, and speed of
running our own test suite on SQLite is pretty important for me at
least. This was already discussed shortly in this thread:
http://groups.google.com/group/django-developers/browse_thread/thread/3f0ca5b957d70423

- Anssi