On 12/19/05, Robert Wittams <[EMAIL PROTECTED]> wrote: > > There are quite a lot of changes in this area being considered in the > magic-removal branch.
I figured as much. Is there any sort of estimated timeframe for the merge of the magic-removal branch into the trunk? > Here are a few example queries. The overriding idea is that the query > objects act like builtin sets as possible, but lazily fetched from the > database. +1. Love it. This hits one of my biggest bugbears about the existing syntax - that you can't decompose a big query into little logical bits, and compose/reuse the bits when you need the query evaluated. > > 4) Create a Join() class (with InnerJoin and OuterJoin subclasses) that > > can be used in the tables clause. > > Exposes raw table names. Embedded string parsing. Bad. Granted. However, I can't see any easy way with the current system to get access to the table/column names. However - the syntax you suggested for #2: > Person.objects.returning( Person.name, Person.age ) provides a solution, as long a django db objects have properties that evaluate to their underlying table/column names. Person.name -> "polls_person"."name" (or can be interpreted/looked up in some way). > I think the main problem with this proposal is readability. You appear > to be thinking in terms of the SQL generated. Strange that... it's because I was :-) IMHO, once you get outside relatively simple examples, the Django syntax encourages you to do so. The 'select', 'tables', and 'where' kwargs are all there to get around the limitations in Django expressiveness. And beyond encouraging SQL-like thinking, they even encourage the embedding of raw SQL. The suggestions I was putting forward were attempts to regularize syntax with the goal of minimizing the amount of raw SQL required. I'm happy to abandon all of them if we can develop an alternate syntax that minimizes the need for any SQL embedding. +1 to the keeping access to raw SQL queries available (at a cursor level) for the edge cases, but -1 to putting the edge so close to the core, requiring this approach for every non-trivial problem. > I think the query syntax needs to be designed with use cases in mind, > rather than "if we do this, we can express lots of sql queries". Thats > nice, but only if its going to be comprehensible, and more usable than > raw sql. Absolutely agree - but I would also make one addition - it has to be comprehensible, more usable, AND have expressive range that covers the most common SQL use cases. I accept that the ability to pose some queries will be lost in any elegant syntax, but if you can't cover a wide range of base use cases, why bother having the syntax at all? IMHO, as it currently stands, Django is missing 2 major areas of SQL functionality: 1) queries over 1-N relationships (get me a list of polls whose choices meet a certain criteria) 2) Aggregate clauses and nothing I have seen in the magic-removal discussions is addressing these omissions. I don't see these as edge cases - every SQL tutorial I have seen that covers more than a single page talks about JOIN and GROUP BY. The only reason I am dancing around the edges of 'select' and 'where' is because I need to do both these things, and cannot with the existing Django syntax. If you want a use case to work with - here's one: A Task has a list of Estimates and a list of Activities. Each Estimate has an integer describing the amount of effort involved, as does each Activity. Keeping the individual estimates/activities is important, so you can't just decompose Task to contain integer Estimate and Activity fields (unless you can propose an alternative audit trail) A task is planned if the number of estimates != 0. A task is complete if it is planned, and sum(estimates) = sum(activity) Now, retrieve a list of all complete tasks. For bonus points: A Milestone has a list of Tasks. A Milestone is complete if it has at least one task, all of which are complete. Retrieve a list of completed milestones. If the outcome of the magic-removal is the ability to express this problem in Django syntax, I'll be a very happy man :-) Russ Magee
