On Tue, Dec 17, 2013 at 4:50 PM, Chris Wilson <ch...@aptivate.org> wrote: > Hi all, > > > On Tue, 17 Dec 2013, Tom Evans wrote: > >> On Tue, Dec 17, 2013 at 3:35 PM, parisrocks >> <saravanan.sellathu...@gmail.com> wrote: >>> >>> Waiting for official Django ORM support for NoSql databases. >> >> >> MongoDB (and the vast majority of NoSQL databases) are not relational >> databases, they are document oriented databases, they store documents of an >> unspecified type and allow you to retrieve documents by id, or perhaps other >> attributes of the document. >> >> At no point with MongoDB can you have relationships between two different >> documents that can be followed or queried. Therefore, I'm quite confused >> what you want from an "ORM" interface to a NoSQL database. Each document has >> no relationships, there is nothing for an "ORM" to do... > > > I think it would be more helpful to say that it IS possible to store the ID > of a document in a field of another, of course, and that means that > documents CAN have relationships:
I really don't. Yes, some NoSQL stores can do semi-relational things (like RethinkDB), and you can, as you demonstrate, store raw ids in the document and use application logic to "make joins", but I think it clouds the issue and makes people think that NoSQL datastores can somehow store their relational data in it and perform relational queries on it, if only those darn developers would write it. It is nonsensical. The 'R' in the ORM is important; if you cant perform equivalent relational queries in the same manner as all the relational databases currently supported by the ORM, then what is the purpose of attempting to shoe-horn it into the same API? Relational and document databases serve different purposes, if you are attempting to do relational logic in a document database, then IMO you're starting out from an invalid position. Nothing prevents you from using both concurrently, of course. I guess the one thing that could be done would be to write a django API interacting with all the different NoSQL engines, but not attempting to mimic the ORM. This would give a "django nosql" solution, without trying to force a square peg into a round hole. Three downsides to this: 1) SQL backends all generate SQL (duh) which means there is a lot of shared code in the ORM. 2) Different stores python adapters can have very different interfaces and features, making it hard to define a base feature set. 3) It's a document database, there is very little involved in looking up and retrieving a document, it's easier just to use the specific adapter for the store you want directly. Cheers Tom -- 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/CAFHbX1LNLwknbVXy_Amo1qaQ%3DUxrBmB7RBrbWJ%2BADE9VCuxYsg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
