I'll say. I haven't been keeping up with the development, but the improvements to the model layer alone are worth the price of admission.
The conditional view processing is another gem, though I'm not sure it'll supplant a real caching engine -- it should at least get wins for those who either opt out of something like memcache, or perhaps haven't gotten around to it yet. Of course, adding it as a supported backend, I can't imagine that happening very often.
I'd view the conditional view processing as complimentary to the cache engine; you can't have too many layers of caching really. Also, conditional view processing can save bandwidth since unmodified responses don't need a body. Bandwidth is a lot cheaper now than just a few years ago, but for some folks this is still a bug deal.
Also, one important "feature" you get for free when using conditional view rendering is that upstream caches -- Varnish, Squid, etc. -- will perform better as well.
So really this new feature is about improving how well Django speaks HTTP, not caching per-se.
Yes, and it allows fine grained control of the conditional view logic within the view as opposed to the generic and coarse default etags/if modified since handling.
Another instance of Django making the simple, simple and the difficult possible.
I'm still not entirely clear on what the benefits of Django's ORM are. isn't SqlAlchemy far more mature and feature rich? Why aren't they moving closer to that?
It's a completely different way of thinking about your data, so there is no question why they don't converge. Django's ORM has a more relational (read traditional) approach, and SQLA tries to have you forget about tables at all. While it is still more powerful Django ORM is catching up with each release.
In fact, with aggregations released in 1.1 you will be able to compose 'group by' queries without resorting to internal query object modification, and there will be very few queries that could not be expressed conveniently in Django ORM.
One thing I'd noticed a while back was that it tends to generate LEFT OUTER JOINS instead of plain old LEFT JOINS, which isn't really bad, But thats one of the reasons (besides just being plain lazy) that I'm still sticking with pl/pgsql functions for most of my aggregation needs.
It's a pretty esoteric feature, I'll grant you, but it's needed to implement several useful, more user-oriented features. The big one is deferred fields, which in certain situations can give apps enormous performance gains. If you're interested in how these features are related, Malcolm lays it all out here: http://www.pointy-stick.com/blog/2009/03/23/yak-shaving-adva...
It's important to understand that often the simplest features have the most complex underpinnings. In other words, simple APIs often require complicated internals.
