On Wednesday, December 26, 2012 at 10:56 PM, Russell Keith-Magee wrote: > That depends entirely on what you consider the goal of the ORM to be. > > You have assumed that the goal would be "allow an arbitrary query to run on > any underlying data store, and run with equivalent efficiency". In this > model, you could take your fully operational Django PostgreSQL project, and > roll it out under MongoDB (or any other supported store), and it would > Magically Workâ˘. > > I completely agree that this is a completely unrealistic goal, and would, as > you rightly point out, constitute a high-calibre footgun. That's what people will expect from it in large part. It may not be what's intended but it's what people will expect. > > However, there's another way of looking at it. You're focussing on the ORM as > a query generation engine. Of more interest is the ORM as a metadata layer > for models in a data store, with some basic reliable querying features. > > Think of it this way -- the goal isn't to allow an arbitrary query to run on > any data store. The goal is to allow Django's admin to operate on a model in > any data store, or to allow a Django ModelForm to retrieve and/or store an > object in any datastore. This can easily be done with 2 (or more) separate systems. There is 0 reason why the Admin and the ModelForms need to only realistically work within a single system. If your goal is to allow someone to use the admin, modelforms, or some other tool to interact with all of them that does _not_ require anything more than basic access then you can define an API that the admin expects and as long as your "Model" fits that API it can be used there. Then you can have one ORM for Relational databases that is able to use the full power of the ORM, one for each of the various "classification" of ORM (which don't even need to live in Django Core) and as long as they implement the interface that the Admin (for example) expect they will work out of the box.
A system like this removes the expectation from users that you can take a model written for a relational database and cram it into a NonRel (and the inverse), allows you to have "shared" consumers of the various implementations, but still have access to the full power of the underlying implementations. > The queries required to support Django's admin and/or ModelForms are all > inherently simple CRUD operations -- operations that have simple (and for the > most part, efficient) analogs in every data store. > FWIW the Admin cannot even currently handle all database tables because of assumptions it makes about performance (so far I've seen it expects `SELECT COUNT(*) FROM <table>;` to return in a reasonable amount of time). Applying even greater diverging performance patterns to it is a harder than you're assuming especially if you take all of the features of the admin into account. -- 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.
