

Django 1.6 alpha 1 released - Lightning
https://www.djangoproject.com/weblog/2013/may/26/django-16-alpha-1/

======
manojlds
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
> 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
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...](http://mixedbit.org/blog/2013/02/06/django_db_pool_on_heroku.html)

I also can't wait to have such mode fully supported by the core product.

------
deepak-kumar
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>

~~~
itafroma
Unshortened URL for the release notes:
<https://docs.djangoproject.com/en/dev/releases/1.6/>

------
speg
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).

~~~
jacobian
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
I'm amazed by the rate of the Django releases lately; the core devs must be
very busy.

------
foobarram
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
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
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
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
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.

------
Aqwis
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
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.

