The headline is sensational, and Mongodb support is a poor yardstick. And, using Rails as _the_ benchmark is another poor choice.
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.
At the core developer Q&A during DjangoCon US this year, it was pretty much universally agreed upon that non-relational database support for the core of your app was too much of an edge-case to bother finishing work on.
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.
NoSQL support is one of the least interesting ways that I find Django failing to keep up.
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.
Can you elaborate on "resolving the manager/queryset/model-method wackiness"? I haven't used another web framework in a while so I'd like to see a comparison to understand your frustrations.
> I'd much rather see catching up with regard to ORM/SQL efficiency improvements, cache infrastructure usefulness
I hope you're talking about Sequel and not that namespace-polluting, memory-consuming, bloated beast called ActiveRecord. In that case, I wholeheartedly agree.
I assume that anyone who agrees with this post doesn't actually do programming, and would struggle to instantiate a Redis client and then use it in the simplest manner.
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.
I would claim thare are benefits in a framework having a similar API for both for SQL-ORM and NoSQL-ODM. This has already been done in the Ruby on Rails world, where ActiveRecord and Mongoid exist in parallel and have similar interfaces. This makes it much easier for third party modules to support both of them.
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.
- 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.
You might be right that the "SQL-agnostic" argument was not well formed. I basically meant that the Django ORM has always been very object-oriented, and it has avoided SQL-specific concepts like WHERE clauses as much as possible. And because of this, it wouldn't be so hard to make it work with MongoDB, except for more complex relations. In fact, this has already been done by django-nonrel for 1.3.
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.
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.
I have used MongoDB as the main database for many small/mid-size web projects and found it to be very flexible compared to MySQL/Postgres:
- 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.
"Django doesn't have the feature I want, so it's doomed to irrelevance." Rails will win, driving a ruby-tipped stake through Django and nobody will be able to use it for anything any more.
[+] [-] wiremine|13 years ago|reply
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.
[+] [-] jacobian|13 years ago|reply
[+] [-] qiller|13 years ago|reply
[+] [-] antihero|13 years ago|reply
[+] [-] powellc|13 years ago|reply
[deleted]
[+] [-] Pewpewarrows|13 years ago|reply
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.
[+] [-] pewarrowspew|13 years ago|reply
[+] [-] famousactress|13 years ago|reply
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.
[+] [-] richardlblair|13 years ago|reply
[+] [-] jordanmessina|13 years ago|reply
[+] [-] rlander|13 years ago|reply
I hope you're talking about Sequel and not that namespace-polluting, memory-consuming, bloated beast called ActiveRecord. In that case, I wholeheartedly agree.
[+] [-] anotherbadlogin|13 years ago|reply
[deleted]
[+] [-] zeeg|13 years ago|reply
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.
[+] [-] kennu|13 years ago|reply
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.
[+] [-] kungfooey|13 years ago|reply
- 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.
[+] [-] kennu|13 years ago|reply
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.)
[+] [-] freyrs3|13 years ago|reply
[+] [-] pydanny|13 years ago|reply
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.
[+] [-] dedsm|13 years ago|reply
[+] [-] GuiA|13 years ago|reply
[+] [-] kennu|13 years ago|reply
- 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.
[+] [-] fduran|13 years ago|reply
Besides, adding mongodb support (including admin) to Django is trivial with pip install django-mongodb-engine pymongo.
[+] [-] peterbe|13 years ago|reply
By the way, if you're interested in being agnostic on your NoSQL backend, take a look at Schematics https://github.com/j2labs/schematics
[+] [-] endgame|13 years ago|reply
[+] [-] beatpanda|13 years ago|reply
[+] [-] misiti3780|13 years ago|reply
https://github.com/django-nonrel/django-nonrel
[+] [-] xxiao|13 years ago|reply
[deleted]
[+] [-] unknown|13 years ago|reply
[deleted]