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. -- 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/6f2bcf71-13bd-40cf-bee8-0f5fb264a5c7%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
