Sorry -- I missed page 2. So GROUP BY and similar things will be supported through an Aggregates base class?
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 -~----------~----~----~----~------~----~------~--~---
