On Mon, Dec 24, 2012 at 7:10 AM, Donald Stufft <[email protected]>wrote:
> On Sunday, December 23, 2012 at 4:08 PM, Florent Gallaire wrote: > > Django ORM should work for SQL and NoSQL DBMS. > NoSQL integration in Django is a more interesting and needed subject, > but who cares about that in the core team ? > > Why should the Django Object Relational Mapper be modified to > work with non relational databases? Trying to shoe horn random NoSQL > into the Django ORM feels like a bad idea. > > Why? Because we've gone to extraordinary lengths to make sure this sort of thing is at least theoretically possible. Although we use the term "ORM", and there's currently only relational implementations of Django's ORM, there's nothing relational about the Django ORM API. We've very deliberately posed the API in terms of functions you want to perform on objects: * Get me the author named "Douglas Adams" * Get a list of books that are more than 3 years old * Update the login counter on this user by one. and so on. Although a relational store can satisfy these queries, there's nothing inherently relational about the queries that are issued; in theory, a non-relational store would be just as capable of answering them, and there's no high-level conceptual reason that Django's admin, or ModelForms, or any of the other Django tools that leverage the model metadata couldn't be backed by a non-relational data store. The only exceptions to this are raw queries, which are, as the name suggest, raw, and extra() clauses, which the docs make clear are pretty close to raw queries anyway. If a non-relational store were to be added to Django, it wouldn't be unreasonable to suggest that analogs of 'raw' and 'extra' would exist. The bigger question is who cares about this in the core team. A few years back, when the excitement about non-relational stores was growing, there was a lot more interest in the core team. There was a Summer of Code project aimed at modifying the ORM to allow the development of third-party non-relational backends. A proof of concept MongoDB backend was developed as part of this effort. The code from this SoC is still available -- although it hasn't been kept up to date with trunk. The changes were relatively minor (and only to internal APIs) -- however, there were some major design problems. In particular, Django's internals make some assumptions about the fact that AutoFields (the default type for primary keys) are always integers, which doesn't hold for many non-relational stores. If you search the django-dev archives, you'll find further discussions on the points that needed design decisions. These days, I'm seeing less interest in non-relational stores from the core team. I'm not saying that non-relational stores are unimportant -- just that nobody in the core team has an itch that currently requires an ORM-level wrapper around a relational store. That said: if a clean, easy to understand (or well explained) patch were to magically appear that resolved all the design issues in a palatable way, I'd guess that someone in the core team could probably be convinced to take the time to review and commit it. Alternatively, if someone were to get the SoC patch up to date, and provide a good analysis of the problems and potential solutions, they would be able to get the attention of the core team to provide a design decisions. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
