On Mon, Oct 26, 2009 at 3:05 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > On Mon, Oct 26, 2009 at 8:46 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> >> On Mon, Oct 26, 2009 at 1:12 PM, Russell Keith-Magee >> <freakboy3...@gmail.com> wrote: >>> To date, sql.Query is the right structure for all Django's supported >>> backends. It might even be the right structure for a non-SQL backend >>> that provides a SQL-like query layer (AppEngine possibly falls into >>> this category, as might a SimpleDB backend). However, a CouchDB, >>> Cassandra or MongoDB backend probably won't get much traction using an >>> internal query structure that talks about Joins and Where clauses. >> >> App Engine's datastore API is more similar to MongoDB than SQL. Even >> on SimpleDB I don't think that the Where tree is a good idea because >> it's way too SQL-specific. > > Exactly my point. There is no such thing as a "generic" internal > query. The closest we can hope for is a common interface for objects > that can have Qs, filters, et all added to them. sql.Query interprets > those Q's and filters as joins. Other backends will require other > interpretations. > [...] > I need to take a closer look at QueryGlue to be able to offer any > deeper critique of this. I'll put this on my todo list.
Yes, that'll help in our discussions and I hope it'll make clearer why query_class() should rather be implemented in our branch instead of multi-db (which already works the way it is - withour query_class()). Here's the link: http://bitbucket.org/wkornewald/django-nonrel-hacked/src/tip/django/db/models/queryglue.py What QueryGlue does is something like this (though, it's simplified): queryset.filter(bla__attr=3) => gets translated to => queryglue.filters_tree.add(( ['bla', 'attr'], 'exact', 3 )) As you can see, there isn't anything backend-specific in the filters_tree. It's actually not even that much different from what sql.Query.add_filter() already does - just without adding information about joins and other SQL-specific stuff. Now, an SQL backend can just iterate over filters_tree and call sql.Query.add_filter() for each child in the tree - this would be the easiest way to make sql.Query work again in our code. OTOH, the non-relational backends could inspect the tree and possibly execute multiple queries - one for each table involved in the query - and then join the result set in memory (depending on the query and your data this can be inefficient - or efficient). Bye, Waldemar Kornewald --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
