On Sun, 2007-02-25 at 18:21 +0100, Honza Král wrote: > On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > I noticed today that a new GIS branch has been created, which includes a > > goal to develop a custom QuerySet-derivative. There has also been a > > discussion on trying to work out an API for aggregates, which seems to > > be moving along, although I suspect the design has a bit more work > > required yet. > > I have a working code, that can handle simple situations (no __ > lookups), it works nice, but to make it work 100% I also found the > need to refactor the queryset. I started on that as well, when in the > first step I just broke up the query generation into more detail, so > that _get_sql_clause doesn't return the FROM WHERE ORDER LIMIT as a > block, but separately, so things can be added there... I just started > on the half an hour ago, but it went smoothly, I then ran into > difficulties trying to get the related__lookups__to__work outside Q > objects ( I thought I would use this notation to specify on which > field to group by etc.)
Sounds like you are doing the same sort of split, but without moving it to a separate class (which is just for maintainability and separation of responsibility, mostly). [...] > > I (and others, especially Russell) have spent quite a while living in > > the current QuerySet code fixing bugs with query construction and > > scratching our heads wondering how on earth we are going to fix some > > other cases. For example, we often don't use the most efficient (or the > > correct -- in some cases) type of table join when constructing queries. > > Joining QuerySets with particular combinations of disjunctions and > > conjunctions when common fields are involved leads to incorrect results. > > Thinking about how to join in support for aggregates just gives me a > > nose bleed, because constructing the GROUP BY and HAVING clauses is > > fiddly. > > its not that bad - I managed to get GROUP BY working, with things as > sum, min, count etc. > getting HAVING to work is quite simple by overriding the filter() ( > well, _filter_or_exclude to be precise ) You'll start to hit a lot of problems when you try to get this working correctly for various intersected and joined queries (combinations of "and" and "or") and possibly in other more advanced usages. Basically, it gets fun when table aliases start to appear and when you want to use multiple join types (we pretty much always use "left outer" which is inefficient in some cases and just plain wrong in some other cases -- it works most of the time, though). You have to work with things in the right order. I got GROUP BY and HAVING working in the more straightforward cases, too. Then the wheels fell right off when I got to more advanced cases. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
