On Mon, Oct 26, 2009 at 4:52 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > > On Mon, Oct 26, 2009 at 1:46 AM, Russell Keith-Magee > <freakboy3...@gmail.com> wrote: >> The current query_class will need to change slightly to support >> multi-db, so anything you implement against that interface will >> require some rework later on. That said, the fundamental approach >> (i.e., the backend tells you what class to use for queries) will still >> be there - it will just be used in a slightly different way. > > In the SVN multi-db branch there is a modified query_class() API. > OTOH, on github it got replaced with SQLCompiler. Are the > query_class() changes already committed somewhere?
No, they haven't been developed yet. Alex and I did the initial design work at the DjangoCon sprints, but we haven't actually implemented anything yet. > Why do you still need query_class() if you already have SQLCompiler? > If this is just about making non-SQL backends work then you'll need > some kind of backend-independent query representation, so > QuerySet.using() can be supported. That's exactly what we've already > done with QueryGlue, so maybe you should better reuse what we've > started and finish that together with us, so we all don't waste time > on refactoring everything twice? There are two different agents at work here. We need to split sql.Query from QueryCompiler to support the fact that the same SQL-like query needs to be rendered in different ways by different backends. This can be as simple as the character used for quoting, or as complex as wrapper clauses needed to handle LIMIT and OFFSET. There is a separate issue of determining if sql.Query is the right internal structure to use for representing a query. 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. 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. 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. 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 -~----------~----~----~----~------~----~------~--~---
