On Wed, Dec 31, 2008 at 8:43 AM, Justin Bronn <[email protected]> wrote: > >> I'll be looking into this, this week. >> Good news is: So far so good (But I haven't tried to mix geo aggregates with >> new aggregates yet). > > OK, in the GeoDjango 1.1 mercurial [1], I've merged in Russell's > aggregation branch and modified the aggregate geographic methods to > internally use the new aggregation API. Thus, there's now a > corresponding geographic aggregates module that contains Extent, > MakeLine, and Union.
Thanks for this, Justin. I've committed your changes to my github repository. > I had to patch the aggregation branch a bit to make it amenable to > subclassing. Specifically, I made the `aggregates` module an > attribute of Query and `normalize` a Query method so I could > substitute in the geographic aggregates module and be able to convert > geographic aggregate values. These patches are attached to #3566 > (queryset_modular_aggregates.diff). I actually like this change - it allows me to clean up the API for add_to_query so that we don't have to pass in the aggregates module as an argument every time. I've also made a couple of minor naming changes: - the normalize() function has been renamed _normalize_aggregate() - it isn't really a function for public consumption, and it doesn't have applicability outside of aggregates - I've renamed Query.aggregates to the Query.aggregates_module so that the factory module doesn't get confused for a list of aggregates in the query or some other instance-specific structure. Russ %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
