On Tue, Mar 26, 2013 at 6:49 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Wed, Mar 27, 2013 at 12:46 AM, Javier Guerra Giraldez > <jav...@guerrag.com> wrote: >> >> since there's no such thing as "common NoSQL features", each datastore >> would need its own modifications, so i think the common attitude is >> that most of these features don't belong in the ORM. > > > I'm not sure where you've got that impression. Django's ORM was > *specifically* designed in a way to allow for NoSQL backends. Look at the > architecture of the django.db module -- there's a query module, and a sql > submodule. There's very little SQL content in the base query module. That's > so that we can add a "noSQL" module at some later date. We've also been > aggressive about adding SQL-specific features (e.g., HAVING clauses, GROUP > BY clauses) to the ORM API.
i didn't say (and i don't believe) that the ORM is tied to SQL. it certainly could use other kind of backends. What i did say (and still think) that NoSQL is too broad to just be a backend (like "the study of non-elephant animals"). I think the only thing most of NoSQL datastores have in common is that you start most queries with some sort of key; but once you get there, they all diverge widely. my advice (and slight experience) is that it's just Python, you can use any datastore you wish. Also, the loose-coupling of templates means you can give them any record-like object instead of an ORM record, and any sequence-like object instead of a queryset. what you do lose is the ability to unwind related data objects from a single record, or further filter the queryset, but: a) most NoSQL stores don't care about relationships, and b) some NoSQL stores can't handle record filtering > There's a *very* clear high level API picture of how NoSQL integration to > the ORM API would happen. See the design discussions around the NoSQL GSoC > project for more details. AFAIR, there were two sides: A) focus on common features B) emulate some features on backends that don't provide them my position is that the A solution quickly becomes an empty set, so i a way, it's already done! The B option is interesting but the performance/scalabilty profiles of each feature is completely different on different backends, so it could be misleading to wrap on the same API. Still, i do like the "quack this way" observation. Just by formalizing some defined protocols for the most useful features, we get a big boost in aplicability. some easy to convene suggestions: - make collections iterable as python sequences. bonus points if you handle [start:end] slices - if you handle filtering in a collection, use the .filter(condition=value, cond2=val2) style on the collection object - if you handle relationships, expose them as attributes on a "record" object. these could be records or collections. > What we *don't* have is a huge amount of interest in actually doing the work > to make NoSQL a development priority. NoSQL generated a lot of buzz a few > years ago, but now the buzz has died down, sober heads have prevailed, and > it's become clear that a well configured PostgreSQL store is easily a match > for a NoSQL for most use cases. wholeheartedly agree -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
