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. >> So - the intention is to repurpose query_class() slightly. Once >> refactored, query_class() will be required to return a class that >> implements the Query interface. sql.Query is the only example at >> present, but other backends can provide other internal >> representations. The call to query_class() will be made in QuerySet - >> not as part of the sql.Query construction. In this way, query_class() >> becomes the "get me the actual implementation" method on the backend. > > Why do you want to implement this in multi-db if it's only useful for > non-SQL support? Shouldn't you better keep multi-db as-is and add the > query_class() feature to our branch? That would save us lots of > conflicts because won't have to implement our code twice (once for the > old query_class and once for your version) and we'll probably have to > change your query_class, anyway. Because the way query_class() is currently used causes other problems. Providing an entry point for multi-db is a bonus. >> We're *not* trying to build a completely generic internal query >> representation. I'm not convinced that such an animal is even possible >> in the general case - again, JOIN means something to relational >> databases, but doesn't mean much to non-SQL databases. If AppEngine is >> able to leverage some of the sql.Query internals, thats great - but I >> don't expect that this will be the default situation. > > Does this mean you'll remove QuerySet.using()? Otherwise you'd have to > transform an sql.Query to an appengine.Query. QuerySet.using() will continue to exist. However, I expect there will be some restrictions on when you can call it. Retasking across backend types will be one of those restrictions. > If the generic query representation is not much more detailed than Q > objects then I don't see a big problem, anyway (our QueryGlue can be > easily transformed into sql.Query or any other query type exactly for > that reason). The point why we need QueryGlue is that the queries will > have to be manipulated and interpreted in order to emulate certain > features (e.g., joins) and its much easier to do this on the final > query tree than on its intermediate states. 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. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
