On Thu, Dec 19, 2013 at 1:18 AM, <chris.fores...@vokalinteractive.com>wrote:
> > > On Tuesday, December 17, 2013 8:12:43 PM UTC-6, Russell Keith-Magee wrote: >> >> >> My claim is that complete abstraction of the data store shouldn't be the >> goal. What we should be aiming for is sufficient API compatibility to allow >> for two things: >> >> * ModelForms wrapping a model from a NoSQL data store >> * An admin representation of a NoSQL data model. >> >> These two functions don't require complex relations. They require >> relatively simple CRUD operations on a single object; they require an >> implementation of filter, but not an implementation that allows joins of >> any kind inside a filter clause. Yes, this will cut off some functionality >> -- some custom filters, for example, won't be possible. It might be >> necessary to remove total object counts in admin ListViews -- but then, >> that would be a good performance boost for PostgreSQL as well. >> >> But broadly speaking, I see no reason why it shouldn't be possible to put >> store a data model in NoSQL, and visualise the contents of that model in >> admin. And you should be able to throw up a Form wrapping that data model. >> >> I see two ways to achieve this goal. The first is to put an alternate >> backend into Django's existing ORM. This is the approach attempted by Alex >> in his GSoC project. It's possible, and actually doesn't require that much >> work; but there are a couple of unresolved issues, mostly around handling >> of non-integer automatic primary keys. These are problems that we might be >> worth addressing anyway, because UUID-based auto primary keys would be a >> worthwhile extension to SQL data stores. >> >> The second approach is to produce a duck type compatible model API. There >> aren't (or shouldn't be) any instance checks tied to >> django.db.models.Model; as long as your NoSQL layer implements the same >> API, you should be able to drop it into the admin or a ModelForm. Taking >> this approach would have the side effect that we'd have to clean up the >> formal definition of _meta, which in itself would be a nice goal. Added >> benefit -- this approach doesn't actually require any changes to core >> itself -- the ducks can be completely external to Django. The only changes >> to core would be whatever cleanups and documentation the project identifies. >> >> The other, unrelated problem isn't technical at all -- its that that >> enthusiasm for this problem has pretty much dried up in the core team >> AFAICT. I certainly don't have any call for using a NoSQL store in my life >> at the moment. However, if a ready-to-use implementation of either of these >> approaches were to land on our doorstep, I wouldn't resist them being added >> to core. >> > > Wouldn't an easy (i.e. straightforward) solution be to add an Django "ODM" > that mirrors the ORM wherever it makes sense? This sounds pretty close to > your second solution, except choosing SQL vs NoSQL means users make a more > explicit choice whether to use the ODM API vs the ORM API. > Essentially, what you've described here *is* the second solution, with the caveat that in order to maintain basic compatibility with the internals of Django, you intentionally maintain API compatibility between the ORM and ODM with some key aspects of the ORM API - so, for example, MyMongoDBModel.objects.filter() would work, within certain constraints (for example, as long as you only reference local fields). A richer ODM/document API that better exposes the properties of document-based stores would expand on these basics, but the basics are needed so that it's drop-in compatible with the basics of ModelForm and admin. However, this doesn't need to be added to Django's Core, and I'd resist adding it to core unless it can actually demonstrate that it's a genuine abstraction (in the same way that the ORM abstracts the differences between SQLite, MySQL and PostgreSQL). I'm not currently confident that NoSQL stores are at a sufficient level of maturity that this sort of abstraction is possible (or plausible) for anything beyond trivial examples. Remember, SQL has been a work in progress for 20 years as a *published* standard (and another 20 prior to that as an informal one) - the common ground in SQL is well understood at this point. The same isn't true of NoSQL. Yours, Russ Magee %-) -- 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/CAJxq848B38bGLBy-F9mg98WgwpT0e-sHbnMEyrPE_PMN72RpXQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
