On Tuesday, December 17, 2013 12:16:04 PM UTC-5, Aymeric Augustin wrote: > > Django’s ORM is entirely designed to translate between an object oriented > API and SQL. That’s what its name says. It achieves this through roughly > five layers that bride the abstraction gap. > > Django’s ORM is fundamentally tied to SQL. It isn’t a choice, a policy or > a wish. It’s a fact. >
I am one of the committers on the django-nonrel project. We have supported backends for mongodb and google appengine. There are others out there, but they're not part of the nonrel project. So knowing what it takes to use the django ORM to work with a NoSQL DB, I hope I can provide some useful information. There are a few issues that we run into, so you can see that they are not fundamental problems. 1. Things you can do on a SQL system that you can't on NoSQL. - The big ones are joins and aggregates (for some kinds of aggregates on some NoSQL systems). My perspective is that this is the trade off you make when choosing your datastore, so you should know this going in. 2. Things you can do on NoSQL that you can't in SQL. - This is very database specific, so its hard to give examples, but its the same thing that necessitates raw queries. Some things you either can't do in the ORM or you can do better by hand. 3. Assumptions django makes about the underlying datastore. - We have submitted a number of patches to fix these issues, many of which have been merged in. Our fork is becoming less of a fork every day, and I think with django 1.7 (and some changes on our side), we may be able to do away with the fork for at least the app engine backend. Some specific issues: - AutoField is assumed to work only with integers. MongoDB is an outlier here, it uses something called an ObjectId which is an opaque string. This is actually a big one because field validation occurs before you know which database you save to. - Inserts vs. updates. Most NoSQL databases don't make the distinction, there is only a PUT. We have a patch that causes the ORM to basically force_insert on every save, but I think we can do away with this and convert the update to a PUT in our compiler. - django.contrib app. We've had issues where queries in the contrib apps use joins and other unsupported things. We have patches for these, and would like to get them merged but this is tricky because they are liable to break again if core developers aren't aware of the issues. So those are the technical issues, not so complicated IMHO. I can provide more details if anyone is interested. > I can't see a good reason to do that, but maybe others do. In the mean > time, this question will continue to be asked until a position is > officially documented, > > The core team doesn’t issue press releases with official positions :) > However, as far as I know, most core devs would subscribe to Tom’s answer. > Fair enough on not issuing policy proclimations :-) But I think it would be helpful to get some feedback on the question: should django try to 'open up' the ORM to make it easier to write backends for NoSQL DBs? Add more hooks, sharper divisions between layers, etc. --Alex -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dabe9a2c-e211-4c16-9f1d-21994cead052%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
