Point taken with the criticism; it isn't a particularly compact syntax. I wasn't really proposing it as an ideal solution; more of a solution that could be achieved with very little coding effort. It just struck me as an elegant internal symmetry that wasn't being exploited.
However, the reason I proposed it at all is that it fills (however badly) a hole in DB queries that Django seems to have at present. The existing Django syntax is elegant for single level tables, following chains of N-1 relations, or single level 1-N or N-N relations, but not so elegant for chains of 1-N or N-N relations. My motivation is admittedly self centered; the project I am currently working on (details below) has tables that need to be joined 5 deep through 1-N relations to extract meaningful summary information. As far as getting the job done is concerned, I can do what I need by writing raw SQL using cursors; However, the fact that I can't use the Django DB syntax (and the same goes for a few threads on django-users that have requested information about 'group by' clauses) would seem to highlight a deficiency worthy of examination. Of course, this could all be a moot question. If the intention of Django DB syntax is to provide a clean way to avoid SQL for the relatively simple cases, but not to provide a comprehensive SQL avoidance mechanism, then fine. However, if its not, then (IMHO) more discussion is required. I'm not trying to suggest how we should paint the shed (to paraphrase another recent DB query related thread) - I just think it needs to be made clear what type of shed we have. If it's a small shed, fine - it's a pretty nifty shed as is. But if its a big shed, we're going to need a few more beams to hold up the roof when people start putting in the second floor :-) Russ Magee For those interested, my specific problem is something like this: a Project has several Milestones (each with a due date), which has several Features, which has several Tasks. Each Task has a list of estimates (in hours), and an Activity list (each activity in hours). If, for any given task that has both estimates and activities, SUM(Estimates)-SUM(Activities) = 0, the task is complete; a feature is complete if it has tasks and they are all complete, and so on. Now, give me a list of all incomplete projects with overdue milestones, keeping in mind that on some tasks, activity > estimate, so you can't just take a sum over all tasks for all features for all milestones.
