On Wed, Dec 1, 2010 at 4:34 AM, Jonas H. <jo...@lophus.org> wrote: > Hello List! > > I'm working on queries on embedded objects for Django-nonrel (more > precisely, djangotoolbox) that will use JOIN-like syntax. > > For this, I need to know how to distinguish > .filter(spam__op=eggs, foo__op=bar) > from > .filter(spam__op=eggs).filter(foo__op=bar) > > in the .where tree used in django.db.models.sql.query.Query. > > My first idea was to guess the original query expression from the where > tree's structure, but I suspect that will work out for all kinds of queries > (using Q objects in particular). > > So -- is it possible? How do the SQL backends decide when to do one JOIN > with two SELECTs or two JOINS with one SELECT each?
The problem here is that this isn't handled purely on the where tree. You need to read the Where tree and the joined table list in concert. The list of tables gives you the table aliases, and the Where tree references those aliases. The SQL backends don't do any evaluation of whether one join or two joins are required; that decision is handled by the way add_q is invoked. The single-filter version turns into a single Q addition to the query; them multiple filter version turns into one add_q call for each filter clause. The use of a single Q clause is what controls the join behavior. You *might* be able to reverse engineer the filter() statements from the where tree plus table list, but it's not going to be trivial, and there aren't any built-in tools to do this. 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-develop...@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.
