> Did you guys consider providing a Document class that is entirely > separate from models.Model? > > Technically speaking teaching the ORM non-relational tricks is of > course possible but in reality the philosophy is entirely different > and you need to plan for NoSQL from the very beginning. Traditional > models are flat and have a schema, NoSQL documents can have extra > fields and each of them can hold a fairly complicated structure, > possibly involving numerous other (python-enforced) schemas at > different points in the tree.
Maybe it is inevitable that this kind of debate will crop up in any discussion of django-nonrel or NoSQL, but I very much hope that the philosophical debate does not detract from this fact: that django- nonrel has demonstrated in very real terms that the actual changes needed for Django's ORM to interface with a diverse set of non- relational systems, are, in the general scheme of things, relatively minor. Because they are localized and relatively minor, if those changes do not have a negative impact on the usability and stability of the ORM, and if they do not introduce noticeable backwards incompatibility, that small set of changes should, in my opinion, be considered for acceptance into Django. That being said... The idea that relational and non-relational systems represent entirely different philosophies is very much the conventional wisdom, but I think that when such an argument is made people often ignore the fact that object-oriented systems are just as dissimilar from relational systems as are non-relational data stores, if not more so. In fact, I think that most people would say that many so-called non-relational systems map to object-oriented systems with less "impedance mismatch" than relational systems do. The fact that django-nonrel and Alex Gaynor's GSoC project last year each took similar paths to providing non-relational functionality, arrived at independently, and that both projects required rather minimal changes to the ORM, bears this out, I think. It demonstrates that Django's ORM does not easily accommodate non-relational systems by accident, but because the generalized representation of persistent data that is an "ORM" is as good a match for many so-called NoSQL systems as it is for RDBMSs. > In the end you won't be able to move models or logic between > traditional RDBMS and NoSQL engines anyway. What we get instead is > either a whole bunch of NotImplementedErrors or a heap of hacks to > simulate traditional relations in a world that does not need them. It is also important to note that some "NoSQL" systems are more appropriate than others to be represented in an object-mapping system like Django's ORM. A redis backend, for instance, might look like a bit of a hack, but a backend for App Engine or MongoDB would implement a large and almost complete subset of the ORM functionality without any major hacks. And what is wrong with ORM backends implementing different subsets of the "full" set of ORM functionality? Already that is the case with the supported databases. Sqlite, for instance, doesn't enforce most of the constraints that the other database systems enforce. MySQL myisam does not implement transactions. Etc. Now, there has been much debate regarding hacks that are required in order to implement certain relational functionality in the ORM. The most obvious one is the question of how to handle query joins. It is important to note that simulating query joins is *not* something that django-nonrel does; query joins are simply not supported (just as they are not supported between separate databases with multi-db enabled). The modifications that django-nonrel makes are much more localized and trivial than that; many are on the order of "changing the datatype of a field from an integer to something more generic to accommodate non- integer primary keys". > Of course as much of the ORM API as it makes sense should be supported > by the Document but I really feel these should be designed as separate > object types. I think that my own personal experience might be relevant here. I use RDBMSs in by day-to-day work, and I have worked with RDBMSs in a professional capacity for over a decade. I have played around with django-nonrel quite a bit, but only experimentally. I have no "skin in the game" as it were, no professional or personal reason to want to see this integration move forward, except in this regard: having made a big professional commitment to Django, I want to see it become as popular and ubiquitous as possible, and I want to have the opportunity to use it in as many contexts as possible. Making those changes to Django trunk that would allow non-relational database adaptors to be written without patching Django would be great for Django, as a *product.*. How? It would turn the Django ORM into one of the best (certainly one of the first, if not, at this point, the only) common abstraction layers sitting atop both non-relational and relational systems. SQL long ago came to serve that purpose for RDBMSs, but no similar abstraction layer has emerged for non- relational systems. And yet, somehow, Waldemar and Thomas have been able to create something that serves that very purpose, by simply making small adaptations to Django's existing ORM. I really hope that the Django community recognizes how astoundingly great that is. But on a more mundane level, consider this: using any object other than django.db.models.Model as the base class will mean that any application that uses a non-relational system will have to be written specifically to use a non-relational system as a backend. That means that none of the contrib aps, nor many third-party apps could be reused with a non-relational system; most importantly, the Admin becomes very hard, if not impossible to use. If you want to host your Django app on Google AppEngine, you really need the interface to Google's data store to be implemented as Waldemar and Thomas have done it, as a backend to Django's ORM. Regards, Eduardo > -- > Patryk Zawadzki > I solve problems. -- 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.
