That said, as a full-time Django developer, the headline resinated with me, although I can't put my finger on exactly why. It feels like the last 3 releases (1.3, 1.4, the 1.5 betas) have been lacking in terms of their vision and scope.
Some things I'd appreciate seeing:
* Cleaning out django.contrib, and shifting to a more modular methodology for not-quite-core functionality.
* The default settings.py is just downright laughable compared to what one typically uses for production. Rolling your own environment-specific files (ala local_settings.py) could also use some attention.
* Django admin is still a killer app, but the visual design is long in the tooth. Integrating twitter bootstrap, Zurb's foundation (or any modern HTML/CSS framework) would be a huge improvement.
* Merging South (or any db migration system) into core would be great.
* Revisiting management commands (both the layout and the features) would be great.
* Easier/cleaner support for eventlet or gevent would be nice. At least at the routing and view level.
* PKs with some sort of UUID
* A vision for loosely coupling apps together. 1.5 will be including custom User models, which is handy, but doing something globally would be great. It will always be up to individual app developers to get to the last mile, but some sort of plumbing in Django core would be very handy.
The aim is to refresh the admin frontend without polluting it with extra python code.
I used MongoDB for a year and a half. For 99% of projects that I see on HN and hear about IRL, I'm comfortable saying that you don't need that as your core database. Consider it for the portion of your domain that actually needs nonrel benefits (such as analytics), along with others like Couch, Redis, or Riak.
Your thinly-veiled CRUD app with a social layer doesn't need MongoDB. Here's a nickel, go use a real relational system like Postgres that makes sense for the meat of your data.
I'd much rather see catching up with regard to ORM/SQL efficiency improvements, cache infrastructure usefulness, resolving the manager/queryset/model-method wackiness, or a half dozen other things where I feel like I don't have much argument to make w/ Rails folks when it comes to comparing the frameworks.
It's production-worthy, but the tax it levies on your soul probably isn't worth it.
The idea that if I want to do either:
... I need to implement short() and blonde() on Manager and QuerySet classes for the model. Creating chained query filters like this ought to be easier, and encouraged IMHO.
I hope you're talking about Sequel and not that namespace-polluting, memory-consuming, bloated beast called ActiveRecord. In that case, I wholeheartedly agree.
Really though, in this case I just wish Django would do better than it does now.. or at least better than it did in prior versions . There's hope though, @akaarial appears to be kicking ass and taking names in this area lately.
: https://code.djangoproject.com/ticket/10790 and https://code.djangoproject.com/ticket/18785
You cant have a RELATIONAL mapper without a RELATIONAL database, and you break nearly all of the constraints with many of these "NoSQL" solutions that the Django ORM relies on.
If you want to use NoSQL, use it. There's no reason the Django ORM needs to support it. Programming isn't hard.
Perhaps ideally, the ORM API is a superset of the ODM API with added support for transactions and deeper relations etc. Apps that don't need those features can then easily support both.
You also are only talking about MongoDB. Who cares about MongoDB? Maybe you do. What about the guy using Cassandra? Or Redis? Or Couchbase? etc etc etc
They all have very different properties, and the only thing they have in common is that they store data, and some of them allow you to query on the data.
- The headline is sensational (goes from "Django doesn't support NoSQL" to "Django is falling behind").
- Author says Django "claimed to be SQL-agnostic" then goes on to conclude that it isn't because it doesn't support NoSQL data housing. What? SQL-agnostic doesn't mean storage agnostic. It means /SQL/-agnostic.
If anybody thinks the article was satire, it was not. In fact it was written during a MongoDB conference. ;-) I really am worried that as MongoDB has passed the hype phase and is now becoming a regular and supported part of web technology stacks, Rails is the only heavy-weight framework/ecosystem that really supports it.
I also think that MongoDB currently adds most value to small/mid-size web projects, whose development speed can benefit from the schemalessness and other flexibility compared to RDBMSs. It's not that relevant whether it can actually be used to build the next Facebook or Twitter.
(I wrote the original article.)
Also, why not just use Postgres with Hstore? All the benefits of MongoDB, but with the bonus of being in a mature, stable database. And integration with Django is trivial.
- No manual database/user creation needed
- No manual table creation needed
- No schema migrations needed
- No nested relations needed, because typical web app data structures fit well as dictionaries/lists
- No extra caching layer needed because of previous point
So basically, your app is simpler, and when you give it to a co-developer who has MongoDB installed, he can just start using it. And when you develop further, you don't have to mess with the schema migrations either with co-workers or when deploying to the server.
Besides, adding mongodb support (including admin) to Django is trivial with pip install django-mongodb-engine pymongo.
By the way, if you're interested in being agnostic on your NoSQL backend, take a look at Schematics