So we're not going to support group by at all, even though is extremely simple? I don't understand why everyone says mine (and Curse's and many other peoples) use of SQL is so uncommon. I'd guarantee almost every developer and I know who writes any kind of scalable code (and I've seen what they've written) uses GROUP BY in SQL much more than just for SUM, or COUNT, or any of those operations.
There really is no logical reason to not allow logic in Django. Even if it's in the extra() clause it's better than not having it. I *refuse* to write raw SQL for something that took 30 minutes to patch in, and I will continue to fork Django until the developers see fit to include logical changes. While many of these are going to be present in qsrf, and qsrf will make everything easier, it doesn't add much of the *needed* functionality for complex projects (again, not everyone is building simplistic blog software with Django). SELECT my_table.* FROM my_table JOIN my_other_table WHERE my_other table.my_table_id = my_table.id GROUP BY my_table.id HAVING COUNT(1) > 1; How do you ever hope to achieve something like this in the ORM without patches like mine? This is a very useful query, and we used it heavily for tagging applications, which seem to be fairly common nowadays. Realistically, how do you efficiently want to query for objects that have 2 tags without joining on the table N(tag) times? It seems like a common enough use-case to add in this functionality. You have to understand that DISTINCT doesn't solve every grouping situation that is needed. My main argument is there's no reason to *not* include the functionality except that a few select people say "we dont need it". It's not causing performance overhead. It's not a lot of work. There are patches already made (and if they're not on trac I have them locally). I really don't want to have to switch to Storm, or Alchemy, because honestly, I love Django's approach. The more I'm building complex projects though, the more headaches I'm having, and this is mainly due to the ORM being so damned limited, and databases being so complex. On Mar 18, 6:36 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Wed, Mar 19, 2008 at 9:26 AM, Justin Fagnani > > <[EMAIL PROTECTED]> wrote: > > Hey Nicolas, > > > It seems to be a bad week to have this discussion with all the main devs > > busy with the PyCon sprint and aggregation not being a top priority, but I > > want to see if I can clarify my objection to the field__function=alias > > syntax so that hopefully we can be on the same page and not have duplicated > > proposals and work. Hopefully the core devs can check this out after this > > week. > > You may not have _all_ the core developers attention, but _some_ of > them are listening - I'm definitely reading everything, and responding > when I get a chance; Malcolm is evidently reading too. > > This doesn't mean that aggregates are a low priority. They are > certainly a high priority for me. I'm sure Adrian and Jacob have > noticed the discussion, and they will have also noticed that Malcolm > and I are involved. They probably won't say anything until Malcolm or > I ask them for an official judgement, or until they see something that > Malcolm or I are supporting that offends their sensibilities. > > I haven't been as responsive as I was hoping to be on this thread - > I'm in the process of doing a project handover at work, and the > weekend was hectic for me personally; with luck, I should be able to > give you some more in-depth feedback on your proposal in the next day > or so. > > > 1) My first, and main, objection to the syntax is that it's simply > > unnecessary > > > 2) It's magic. Again, even though the filter syntax is a little magical, > > but it was necessary. > > > 3) It overloads __ for yet another purpose > > I disagree. The usage of the aggregate syntax is no different to the > filter syntax in rendition or interpretation, except that the > 'functions' are aggregates rather than comparators. '__' is used for > join specification, or function specification in the terminal case. > > The potential for name space clashes is almost nil, since the last > clause in the query term must be the aggregate function. The sum over > a field called sum is sum__sum; the first sum is the field name, the > second is the sum function specifier. > > > 4) It adds more logic to QuerySet/Query and may be hard to extend. > > This is actually one of the aspects of your proposal that I > particularly like. In particular, it provides an entry point for > complex aggregate cases. The example that springs to mind is > aggregates with complex group_by clauses that work over multiple table > joins. > We may not want to provide out-of-the-box support for these complex > cases in the form of a native operator or syntax, but it would be > helpful to be able to provide a clean mechanism for end users to > define 'custom aggregates' in a similar fashion to custom Q objects. > > It also affords all sorts of aggregate math opportunities, as you have > previously indicated. > > 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 [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 -~----------~----~----~----~------~----~------~--~---
