5 ms·

Django 1.6 alpha 1 released

126 points by Lightning 13y ago

deepak-kumar 13y ago
Good. Keep it coming. For those who are interested further, here are the release notes to see "What’s new in Django 1.6" http://j.mp/13XRnoD http://j.mp/13XRnoD
- itafroma 13y ago
  Unshortened URL for the release notes: https://docs.djangoproject.com/en/dev/releases/1.6/ https://docs.djangoproject.com/en/dev/releases/1.6/
manojlds 13y ago
This is the most exciting and interesting thing in the release: Persistent database connections Django now supports reusing the same database connection for several requests. This avoids the overhead of re-establishing a connection at the beginning of each request. For backwards compatibility, this feature is disabled by default. See Persistent connections for details.
- elithrar 13y ago
  > This is the most exciting and interesting thing in the release: Absolutely. My expectation is that this alone should dramatically increase app response times for any reasonably DB-dependant application.
  - mixedbit 13y ago
    It does. You can currently do this with an external Django DB Pool module, for some numbers see: http://mixedbit.org/blog/2013/02/06/django_db_pool_on_heroku.html http://mixedbit.org/blog/2013/02/06/django_db_pool_on_heroku... I also can't wait to have such mode fully supported by the core product.
  - Kiro 13y ago
    Typo or sarcasm?
- dodyg 13y ago
  Connection pooling? I am surprised to find out that Django doesn't have this feature until now. Is there any specific reason why this wasn't implemented much earlier? Old tech like plain asp had this more than a decade ago.
  - niels 13y ago
    There are external apps that provide this. https://github.com/gmcguire/django-db-pool https://github.com/gmcguire/django-db-pool https://github.com/kennethreitz/django-postgrespool https://github.com/kennethreitz/django-postgrespool https://github.com/niwibe/djorm-ext-pool https://github.com/niwibe/djorm-ext-pool
- est 13y ago
  So, when will we have prepared statements upon persistent connections? This would be the biggest speed up of all factors.
  - rbanffy 13y ago
    As soon as someone decides to develop it. Remember: Django is open source software, maintained by a community of competent, dedicated and exceedingly generous developers who give us the privilege of using their software for free.
- SiVal 13y ago
  I just read through the entire, long release document, which listed dozens of changes, large and small. Not a single mention of Python 3 that I could see (though, of course, I could have missed it.) This was supposed to have been the first version of Django in--how many years?--that the version of Python you could build production websites with was the current Python, not a legacy. That this fact is not the headline, and apparently not even considered worthy of mention in a long list of "miscellaneous" items, suggests that those of us who aren't legacy Python 2 users (and don't ever intend to be) just aren't Django's target market. Django has been around for a relatively long time accumulating so many long-time users that I understand the desire to make supporting those who long ago entrusted their businesses to Django the #1 priority. The flip side of that, though, is that those of us without such a legacy would seem destined to be lower priority, maybe significantly lower, for at least a few more years. If there is no Flask in the next year or so that is redesigned to focus primarily on Python 3 web dev, we'll still use Python 3 for various tasks, but for web dev it might make more sense for us to just move on to another language with a more-recently-designed framework.
  - crdoconnor 13y ago
    Django has supported python 3 since version 1.5 - the last major release: https://docs.djangoproject.com/en/dev/topics/python3/ https://docs.djangoproject.com/en/dev/topics/python3/
    - itafroma 13y ago
      > Django has supported python 3 since version 1.5 - the last major release Python 3 support in 1.5 was marked as "experimental"[1], with 1.6 being the release that was supposed to be marked as suitable for general use. I believe that's what GP is referring to. [1]: https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3 https://docs.djangoproject.com/en/dev/faq/install/#can-i-use...
    - SiVal 13y ago
      Yes, but 1.5 claimed only "experimental support", adding that they thought it probably would work all right but didn't want to recommend Python 3 for production yet. The unqualified "yes, we now consider it ready and can recommend Python 3 for production," was promised for Django 1.6. They probably have achieved that goal, but the fact that there is no mention of it anywhere in a document that mentions so many other things suggests that "for the first time, we can now recommend the use of Python 3 for production" isn't something they think their target market cares about as much as the several dozen other "issues" they DID mention.
- yuvadam 13y ago
  I would take a look at the actual implementation [1]. It is clearly not a full-featured connection pool. Sure, it gives some quick performance wins within each thread, but this is no proper cross-process connection pool. [1] - https://github.com/django/django/commit/2ee21d9f0d9eaed0494f3b9cd4b5bc9beffffae5 https://github.com/django/django/commit/2ee21d9f0d9eaed0494f...
Aqwis 13y ago
Are there usually this many backwards-incompatible changes? In the past I've usually been able to upgrade Django without having to do any significant changes in the code.
- ubernostrum 13y ago
  So, it's a big list. But a lot of them are either: * Fallout from transaction changes. Whether this affects your code will vary, and when and how it can affect your code is documented, or * Bugfixes: lots of the stuff in there consists of "we had a bug, we fixed the bug, but you should know this in case you relied on the buggy behavior". Split those out and it's actually quite a bit shorter.
foobarram 13y ago
Pardon my ignorance but, `Persistent database connections` Is this the same as pgBouncer connection pooling? It does sound like the same - but unsure. I just spent a week learning and configuring pgBouncer! :(
- jacobian 13y ago
  Not exactly. It's not proper connection pooling -- for that, you still should be using an external pool like pgbouncer. Instead this is a single persistent connection per thread. The speed improvement should be about the same, but you something like pgbouncer gives you more control over the number of connections and offers a ton of extra features.
  - foobarram 13y ago
    Thank you very much for the clarification `jacobian` - I am assuming that django's connection pooling on 1.6 would still play nice with pgBouncer.
    - jacobian 13y ago
      Mmmm.... I mean, it would, I guess, but I wouldn't recommend using both unless you can show a marked speed improvement over just using pgbouncer. A real connection is (probably) better than persistent connections, so you probably only need the one. Now, I've not benchmarked this, so it's just a guess. Further, the specific performance characteristics will depend on your specific setup -- particularly upon where you have pgbouncer running -- so the only real answer is to benchmark and see. New Relic does a good job showing time spent connecting to the db, fwiw, so you may want to give that a try.
      - foobarram 13y ago
        Thanks again for your answer - I have noted this down now. I will benchmark both cases (CONN_MAX_AGE and PgBouncer) and see which one is faster. Would like to thank you (!!) for the awesome python framework - Django.
speg 13y ago
Have they moved to a faster release schedule? I feel like 1.5 just came out and we can already expect 1.6 in August (not that I'm complaining about it).
- zalew 13y ago
  probably because 1.5 was the first release that didn't block master branch during the feature freeze period, so work targetting 1.6 was already progressing on master during the 1.5 bugfixing schedule.
- jacobian 13y ago
  We're trying to, yeah. For this release specifically we wanted to have it out before the end of summer so that we can be ready to merge Andrew's migration work and any GSoC code and turn around another release quickly.
vonseel 13y ago
I'm amazed by the rate of the Django releases lately; the core devs must be very busy.

126 points by Lightning 13y ago

Good. Keep it coming. For those who are interested further, here are the release notes to see "What’s new in Django 1.6" http://j.mp/13XRnoD http://j.mp/13XRnoD

itafroma 13y ago
Unshortened URL for the release notes: https://docs.djangoproject.com/en/dev/releases/1.6/ https://docs.djangoproject.com/en/dev/releases/1.6/

manojlds 13y ago

This is the most exciting and interesting thing in the release: Persistent database connections Django now supports reusing the same database connection for several requests. This avoids the overhead of re-establishing a connection at the beginning of each request. For backwards compatibility, this feature is disabled by default. See Persistent connections for details.

elithrar 13y ago
> This is the most exciting and interesting thing in the release: Absolutely. My expectation is that this alone should dramatically increase app response times for any reasonably DB-dependant application.
- mixedbit 13y ago
  It does. You can currently do this with an external Django DB Pool module, for some numbers see: http://mixedbit.org/blog/2013/02/06/django_db_pool_on_heroku.html http://mixedbit.org/blog/2013/02/06/django_db_pool_on_heroku... I also can't wait to have such mode fully supported by the core product.
- Kiro 13y ago
  Typo or sarcasm?
dodyg 13y ago
Connection pooling? I am surprised to find out that Django doesn't have this feature until now. Is there any specific reason why this wasn't implemented much earlier? Old tech like plain asp had this more than a decade ago.
- niels 13y ago
  There are external apps that provide this. https://github.com/gmcguire/django-db-pool https://github.com/gmcguire/django-db-pool https://github.com/kennethreitz/django-postgrespool https://github.com/kennethreitz/django-postgrespool https://github.com/niwibe/djorm-ext-pool https://github.com/niwibe/djorm-ext-pool
est 13y ago
So, when will we have prepared statements upon persistent connections? This would be the biggest speed up of all factors.
- rbanffy 13y ago
  As soon as someone decides to develop it. Remember: Django is open source software, maintained by a community of competent, dedicated and exceedingly generous developers who give us the privilege of using their software for free.
SiVal 13y ago
I just read through the entire, long release document, which listed dozens of changes, large and small. Not a single mention of Python 3 that I could see (though, of course, I could have missed it.) This was supposed to have been the first version of Django in--how many years?--that the version of Python you could build production websites with was the current Python, not a legacy. That this fact is not the headline, and apparently not even considered worthy of mention in a long list of "miscellaneous" items, suggests that those of us who aren't legacy Python 2 users (and don't ever intend to be) just aren't Django's target market. Django has been around for a relatively long time accumulating so many long-time users that I understand the desire to make supporting those who long ago entrusted their businesses to Django the #1 priority. The flip side of that, though, is that those of us without such a legacy would seem destined to be lower priority, maybe significantly lower, for at least a few more years. If there is no Flask in the next year or so that is redesigned to focus primarily on Python 3 web dev, we'll still use Python 3 for various tasks, but for web dev it might make more sense for us to just move on to another language with a more-recently-designed framework.
- crdoconnor 13y ago
  Django has supported python 3 since version 1.5 - the last major release: https://docs.djangoproject.com/en/dev/topics/python3/ https://docs.djangoproject.com/en/dev/topics/python3/
  - itafroma 13y ago
    > Django has supported python 3 since version 1.5 - the last major release Python 3 support in 1.5 was marked as "experimental"[1], with 1.6 being the release that was supposed to be marked as suitable for general use. I believe that's what GP is referring to. [1]: https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3 https://docs.djangoproject.com/en/dev/faq/install/#can-i-use...
  - SiVal 13y ago
    Yes, but 1.5 claimed only "experimental support", adding that they thought it probably would work all right but didn't want to recommend Python 3 for production yet. The unqualified "yes, we now consider it ready and can recommend Python 3 for production," was promised for Django 1.6. They probably have achieved that goal, but the fact that there is no mention of it anywhere in a document that mentions so many other things suggests that "for the first time, we can now recommend the use of Python 3 for production" isn't something they think their target market cares about as much as the several dozen other "issues" they DID mention.
yuvadam 13y ago
I would take a look at the actual implementation [1]. It is clearly not a full-featured connection pool. Sure, it gives some quick performance wins within each thread, but this is no proper cross-process connection pool. [1] - https://github.com/django/django/commit/2ee21d9f0d9eaed0494f3b9cd4b5bc9beffffae5 https://github.com/django/django/commit/2ee21d9f0d9eaed0494f...

Aqwis 13y ago

Are there usually this many backwards-incompatible changes? In the past I've usually been able to upgrade Django without having to do any significant changes in the code.

ubernostrum 13y ago
So, it's a big list. But a lot of them are either: * Fallout from transaction changes. Whether this affects your code will vary, and when and how it can affect your code is documented, or * Bugfixes: lots of the stuff in there consists of "we had a bug, we fixed the bug, but you should know this in case you relied on the buggy behavior". Split those out and it's actually quite a bit shorter.

foobarram 13y ago

Pardon my ignorance but, `Persistent database connections` Is this the same as pgBouncer connection pooling? It does sound like the same - but unsure. I just spent a week learning and configuring pgBouncer! :(

jacobian 13y ago
Not exactly. It's not proper connection pooling -- for that, you still should be using an external pool like pgbouncer. Instead this is a single persistent connection per thread. The speed improvement should be about the same, but you something like pgbouncer gives you more control over the number of connections and offers a ton of extra features.
- foobarram 13y ago
  Thank you very much for the clarification `jacobian` - I am assuming that django's connection pooling on 1.6 would still play nice with pgBouncer.
  - jacobian 13y ago
    Mmmm.... I mean, it would, I guess, but I wouldn't recommend using both unless you can show a marked speed improvement over just using pgbouncer. A real connection is (probably) better than persistent connections, so you probably only need the one. Now, I've not benchmarked this, so it's just a guess. Further, the specific performance characteristics will depend on your specific setup -- particularly upon where you have pgbouncer running -- so the only real answer is to benchmark and see. New Relic does a good job showing time spent connecting to the db, fwiw, so you may want to give that a try.
    - foobarram 13y ago
      Thanks again for your answer - I have noted this down now. I will benchmark both cases (CONN_MAX_AGE and PgBouncer) and see which one is faster. Would like to thank you (!!) for the awesome python framework - Django.

speg 13y ago

Have they moved to a faster release schedule? I feel like 1.5 just came out and we can already expect 1.6 in August (not that I'm complaining about it).

zalew 13y ago
probably because 1.5 was the first release that didn't block master branch during the feature freeze period, so work targetting 1.6 was already progressing on master during the 1.5 bugfixing schedule.
jacobian 13y ago
We're trying to, yeah. For this release specifically we wanted to have it out before the end of summer so that we can be ready to merge Andrew's migration work and any GSoC code and turn around another release quickly.

vonseel 13y ago

I'm amazed by the rate of the Django releases lately; the core devs must be very busy.