On Wednesday, December 26, 2012 at 10:00 PM, Russell Keith-Magee wrote:
> 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.
Because except for very simple models you will not be able to sanely take a
model written for a Relational database and switch it to a NonRelational
database. If you cannot provide the same sort of mostly transparent switching
like the ORM provides for MySQL -> PostgreSQL -> Oracle then there is little
benefit in keeping it within the same system.
All of your examples work on simple models sure. What about:
* Anything requiring a join, explicitly with select_related() or implicitly
with __ magic.
* select_for_update
* No standard way of handling "Related" fields (Do you Inline them? Mimic a
ForeignKey?)
* The entire transaction system on systems without transactions
There is also the problem of vastly different access patterns, assumptions, and
performance characteristics.
* Getting a list of Books that are more than 3 year old is a very simple
operation in SQL with very predictable performance, getting a list of books
older than 3 years old if they are stored in Redis, less so.
* Systems that depended on a unique=True enforcing a constraint of
uniqueness no longer happening.
* index=True becoming NO-OP.
* A simple Join potentially goes from an inexpensive operation to one that
requires traversing several million rows with horrible performance.
The access patterns, assumptions of functionality, and assumption of
performances are so different between even the different NoSQL solutions, much
less the various NoSQL solutions and Relational databases that either you're
going to have second class citizens (Sure you can use X system with Django
models, but only as a competely segregated unit and you can't touch [a list of
features]), or you're going to need to limit the features down to a subset that
all databases can support (We already have this problem with PostgreSQL vs
MySQL vs SQLite, it will be tenfold if we include NoSQL databases). In order to
actually use the power of your datastore you need to use a class of "ORM" that
is designed to work within it's access patterns.
Django as a whole should be avoiding giving people footguns, and attempting to
shove NonRelational databases into the ORM will be providing a massive footgun.
As soon as it happens you'll have a whole host of people attempting to run apps
and sites that depended on things that relational databases assured suddenly
having it yanked out from underneath them and it will be Django's fault for
providing that footgun.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
