5 ms·
Django 1.1 beta released
- jacobian 18y agoThe interesting details are in the release notes: http://docs.djangoproject.com/en/dev/releases/1.1-beta-1/ http://docs.djangoproject.com/en/dev/releases/1.1-beta-1/
- bmelton 18y agoI'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.
- jacobian 18y agoI'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.
- njharman 18y agoYes, 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.
- snprbob86 18y agoI'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?
- piramida 18y agoIt'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.
- pistoriusp 18y agoI'm also very happy about with the editable fields on the change list.
- hajrice 18y agoWOW! This is awesome!
- elv 18y agoI hope they keep focus on simplicity and usability that proxy model thing seems complex and bugmaker to me
- jacobian 18y agoIt'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-advanced-players/ 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.
- gregparadee 18y agoAggregation support alone is worth the upgrade.
- woadwarrior01 18y agoOne 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.