On Mon, Oct 26, 2009 at 1:12 PM, Russell Keith-Magee <[email protected]> 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. > 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. > 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. 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. 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
