Agreed! The changes to transaction management seem pretty solid too. I've found transactions to be pretty somewhat unpredictable at times in the past, so I'm encouraged by these changes.
Currently, Django closes the database connection at the end of each request/response cycle.
In 1.6, Django will optionally not do this; instead, a setting can specify the maximum amount of time to hold open and keep reusing an existing connection.
This is not connection pooling; that would imply some functionality to actively maintain and allocate connections. This is simply "your process will hold its connection open from one request/response cycle to the next".
Thank goodness. Not being a user of the framework, the lack of database connectivity persistence in Django was among the most surprising elements of setting up the initial test cases in our framework benchmarks project. We've since then added a Postgres test with a connection pool, but I still have the memory of that surprise from the first round.
(Incidentally, I hope to get this new version into Round 7 of our project.)
I really enjoy working with Django, but in many ways, it seems to be staying pretty vanilla while other technologies head in more experimental directions. Does Django have a bright future in a world that's moving heavily client side, or will it be relegated to a relatively bland corner of the web world?
We've got a more complex application (Pathwright) running Django, and we're currently going much more heavy client side. Nothing about Django keeps you from doing this, and there are some excellent third party apps that actually make it very easy (django-rest-framework is awesome).
> Django have a bright future in a world that's moving heavily client side, or will it be relegated to a relatively bland corner of the web world?
This is one of those questions seeking controversy where there is none. Django seems to get out of the way even more when you shift to a heavier client.
I'd be pretty miffed if they did this. You need only look at the comments contrib to see an example of something that was OK'ish when it was incorporated, but has languished since then. Now I question the need to even have it in contrib.
We don't have to bake components in for them to be excellent. rest-framework in particular moves ridiculously fast, and being separate from Django lets them do that. Also, if in the future something even better comes out, I can easily switch to it.
django-rest-framework looks good, been years since I used Django in any seriousness, so will have to give it another run. As an aside, what's the scoop on Python 2.7.X and 3.0 never likely to meet? It makes me uneasy...
I'm not seeking controversy--I really enjoy Django development. It's just that I don't often hear about startups choosing to build in Django (well, besides mine), instead, going with Rails, which seems to have a more active and forward-looking developer community and more aggressive, or flashy new-school stuff like Node/Scala/Go/whatever. I guess what I'm trying to ask is, what is holding Django back? Is it just fashion, or are there more serious perceived shortcomings?
> I guess what I'm trying to ask is, what is holding Django back?
Why do you think it's being held back? I'm just not seeing the barriers in using newer tech. We stay pretty cutting edge, and haven't had any issues doing so with Django.
MTV Video use it. Yahoo use it. Django is massive, but it's like toilet paper or condoms. If you use it, you probably aren't going to blog about it because it's just doing it's job.
Plus, it's not hot new stuff, they largely attempt to make upgrading easy.
Django to me is what .Net is to C#. It's the libraries around the Python language that make it useful.
I don't think Django is being held back at all. It's healthier than it has ever been.
Consider that the reason you don't hear about it isn't due to it not being used but instead to a cultural difference in the people who choose it. I don't think Django developers are particularly good at blogging and self-promotion compared to other projects. They communicate through mailing lists, IRC, twitter, email and documentation. I'm ok with that.
When I started my project, I evaluated a lot of different options and chose Django. One of the big factors was a cultural commitment to documentation and slow measured changes with lots of thought put into backward compatibility. Blog posts about hot startups that are using it is low on my list. (and if you do your research you will see that a surprising number of hot new startups are in fact using it)
I've seen it growing in popularity firsthand. The projects I'm involved with have seen large increases in contributors, mailing list activity, traffic on Github, downloads on PyPi over the last four or five years. PyAtl and some of the other local groups with Djangonauts in them have grown sharply over the last two years (in the Atlanta area). People from other backgrounds are more likely than ever to at least have an idea about what Django is (whereas when I was starting back in 2006 people would just stare at you).
I like playing with Go and the other newer/trendy stuff, but the thing I like about Django is that I can just sit down and get work done fast. It's not sexy, it's not clever, it's not magical, but I don't want it to be any of those things.
As a side effect of this, a huge percentage of the population is too busy getting stuff done with Django to blog and interact, aside from asking questions and getting advice. You know, like Instagram, Pinterest, NASA, National Geographic, Disqus, Mozilla, The Onion, PBS, and many more.
I personally hope django (and rails) keep their focus on the "bland corner of the web." The vast majority of (useful) sites out there are dead dull from a technology perspective, and I'd like tools that help me develop & deploy those types of sites as quickly as possible.
Exactly. I don't want exciting. I don't want magic. I want predictable. I want to be able to pump out high-functioning websites and add features where necessary. Let other libraries handle the bells, whistles, and doo-dads.
I'm thrilled about this particular release, because it includes a significant overhaul of the way joins are built (or rather, trimmed) in the ORM and almost certainly makes your project faster if you do even relatively complex queries:
I'm currently working with Django for a client's project I'm developing. Coming off a LAMP stack binge, the technology itself has been an absolute delight. I've been given the directive to use South to manage the data model, but for future projects I was hoping somebody with more experience can give some insights as to what you've found works and what doesn't work. I'm not the biggest fan of South, but maybe it's just a lack of experience/patience.
I would always use South, but you need to read the migrations and _understand_ what it's doing. When it gets a conflict (and it will), you need to be able to fix up the migrations.
Unfortunately that's the best we have right now. However, the guy who wrote South (and is a core Django developer) ran a Kickstarter last month to raise funds to write South-like functionality directly into the Django core.
£17,952 pledged of £2,500 goal. So it looks like this should be happening. Stated intention as to when:
> As the intention is to get something into Django core itself, the idea is to land this for either the 1.6 or 1.7 release of Django. The work itself should be mainly completed by July 2013, and ready for alpha testing and feedback at that point for those who want to try a development version of Django.
It should help people just getting started with Django to have a smoother transition. I will add various templates with "best practices", like South included by default, stuff like that, to help both me and complete newcomers to easily get started with a new project.
South is pretty great for very simplistic migrations. However, it does not issue DDL efficiently. For example, if you're adding two columns to a table, it will issue two separate ALTER TABLE statements. Depending on your database and table size, that can take twice as long as needed. It can really add up when your tables start hitting millions of records.
I think this is an area where ASP.NET MVC excels because, while REST is nice, you also have to consider web sockets, and I have not seen good web socket support in Django, where ASP.NET has SignalR which is loads easier to configure than a custom solution with Django and Nginx/Apache. Not to mention that SignalR has very nice degradation support on both ends when web sockets are not available.
Well, if you're talking about alternatives that do asynchronism, Comet and Web Sockets well, the most convenient framework I ever used is Play 2.1
The framework is said to be reactive, meaning that you can build components that react to events asynchronously. The architecture is completely awesome, as Akka actors are baked in and the protocols are modelled with Futures and Iteratees, an FP concept for sane I/O. Things like serving unending streams of data and responding to client events using async I/O are in the very foundations of the framework, instead of being taked on later. People using Node.js or Tornado or whatever, don't know what they are missing.
We are using Amazon's EC2 for a huge-traffic web service (because ELB with auto-scalling has been working great for us) and Heroku for auxiliary services.
For websockets, I set the Django framework inside a Tornado thread.
By doing that I lose the wsgi functionality (you get only low level stuff, just like you'll get on java or .net), must synchronize with the normal http server with the DB (what I'll do anyway, since it's the easiest path with Django), and there is some dificulty dealing with signals (the same you'll get with java or .net). And that's all.
Or, TLDR, you lose a few features, that'll make your code resemble a bit more what you'd need to write in java or .net, but preserves most of it.
1.5 was the first release after moving to git - they freeze the release branch and let the rest of development continue on master, so now releases will tend to be quicker (we all hope) hence the surprise with 'early' 1.6. now, since we have an alpha, 1.6 is bugfixed on branch, and 1.7 features can be developped on master like now during the 1.6 release schedule.
Persistent database connections :). Glad to see the objections finally fall by the wayside.
Still no update for the homely admin app? Would love to have it use bootstrap (or similar) to offload look and feel to those focused on it. One extra thing to do in every Django app is to change the ugly yellow on cyan title bar. I know it is already possible with apps, but then it means one more thing to fix on upgrade.
FWIW, admin2 is under active development and moving forward. I don't know if the intention is to replace the existing admin, but as it's not backwards compatible there will be some effort to upgrade if you've completed any serious customization.
I wish the admin started as an external project and stayed that way (for the sake of getting some love and attention). But of course, then we wouldn't be able to show shiny tutorial videos and people wouldn't get it automagically.
I saw this earlier and am absolutely ecstatic over the new template functionality. I can't tell you how many times I've cloned old projects to start new ones, a process which isn't very fun (due to the amount of stuff one needs to change).
I'll post various templates there, for example a default one containing all the "best practices" that I use (and structured that way), one that includes Persona by default (so you can just click the "Log in with Persona button" and log in), etc.
71 comments
[ 3.2 ms ] story [ 128 ms ] threadIn 1.6, Django will optionally not do this; instead, a setting can specify the maximum amount of time to hold open and keep reusing an existing connection.
This is not connection pooling; that would imply some functionality to actively maintain and allocate connections. This is simply "your process will hold its connection open from one request/response cycle to the next".
In what scenario can this be used?
(Incidentally, I hope to get this new version into Round 7 of our project.)
> Django have a bright future in a world that's moving heavily client side, or will it be relegated to a relatively bland corner of the web world?
This is one of those questions seeking controversy where there is none. Django seems to get out of the way even more when you shift to a heavier client.
We don't have to bake components in for them to be excellent. rest-framework in particular moves ridiculously fast, and being separate from Django lets them do that. Also, if in the future something even better comes out, I can easily switch to it.
Why do you think it's being held back? I'm just not seeing the barriers in using newer tech. We stay pretty cutting edge, and haven't had any issues doing so with Django.
Plus, it's not hot new stuff, they largely attempt to make upgrading easy.
Django to me is what .Net is to C#. It's the libraries around the Python language that make it useful.
Consider that the reason you don't hear about it isn't due to it not being used but instead to a cultural difference in the people who choose it. I don't think Django developers are particularly good at blogging and self-promotion compared to other projects. They communicate through mailing lists, IRC, twitter, email and documentation. I'm ok with that.
When I started my project, I evaluated a lot of different options and chose Django. One of the big factors was a cultural commitment to documentation and slow measured changes with lots of thought put into backward compatibility. Blog posts about hot startups that are using it is low on my list. (and if you do your research you will see that a surprising number of hot new startups are in fact using it)
I like playing with Go and the other newer/trendy stuff, but the thing I like about Django is that I can just sit down and get work done fast. It's not sexy, it's not clever, it's not magical, but I don't want it to be any of those things.
As a side effect of this, a huge percentage of the population is too busy getting stuff done with Django to blog and interact, aside from asking questions and getting advice. You know, like Instagram, Pinterest, NASA, National Geographic, Disqus, Mozilla, The Onion, PBS, and many more.
Thank God.
Nice!
Thanks!
The original bug: https://code.djangoproject.com/ticket/10790
Got even worse in 1.4 https://code.djangoproject.com/ticket/18785
Thanks Anssi!
£17,952 pledged of £2,500 goal. So it looks like this should be happening. Stated intention as to when:
> As the intention is to get something into Django core itself, the idea is to land this for either the 1.6 or 1.7 release of Django. The work itself should be mainly completed by July 2013, and ready for alpha testing and feedback at that point for those who want to try a development version of Django.
http://www.stavros.io/posts/django-template-projects/
It should help people just getting started with Django to have a smoother transition. I will add various templates with "best practices", like South included by default, stuff like that, to help both me and complete newcomers to easily get started with a new project.
Where are you getting the data for the client from? Django-Rest-Framework is a very convenient way to get data down into the browser layer from a DB.
I haven't used it personally, and would be very interested to hear others' thoughts.
EDIT: Looking through the example code ( https://github.com/abourget/gevent-socketio/tree/master/exam... ), it doesn't seem as straightforward as one might hope, especially compared to the channels API.
FWIW, I'm using the AppEngine Channels API from my Django app, and have yet to be disappointed with it.
The framework is said to be reactive, meaning that you can build components that react to events asynchronously. The architecture is completely awesome, as Akka actors are baked in and the protocols are modelled with Futures and Iteratees, an FP concept for sane I/O. Things like serving unending streams of data and responding to client events using async I/O are in the very foundations of the framework, instead of being taked on later. People using Node.js or Tornado or whatever, don't know what they are missing.
See their docs on the subject:
- for Scala: http://www.playframework.com/documentation/2.1.1/ScalaAsync
- for Java: http://www.playframework.com/documentation/2.1.1/JavaAsync
Deployment to Heroku works out of the box btw.
Socket.io for node.js is very awesome for stuff like that.
By doing that I lose the wsgi functionality (you get only low level stuff, just like you'll get on java or .net), must synchronize with the normal http server with the DB (what I'll do anyway, since it's the easiest path with Django), and there is some dificulty dealing with signals (the same you'll get with java or .net). And that's all.
Or, TLDR, you lose a few features, that'll make your code resemble a bit more what you'd need to write in java or .net, but preserves most of it.
(He said, sarcastically.)
Seriously, it is GREAT to see the framework continue to roll forward.
Still no update for the homely admin app? Would love to have it use bootstrap (or similar) to offload look and feel to those focused on it. One extra thing to do in every Django app is to change the ugly yellow on cyan title bar. I know it is already possible with apps, but then it means one more thing to fix on upgrade.
https://github.com/twoscoops/django-admin2
Watching this with interest.
I started this right away: http://www.stavros.io/posts/django-template-projects/
I'll post various templates there, for example a default one containing all the "best practices" that I use (and structured that way), one that includes Persona by default (so you can just click the "Log in with Persona button" and log in), etc.
I love this feature.
Edit: please don't downvote me, he's a worthless troll and needs to be put in his place; look at his past comments.