On Tue, Apr 29, 2008 at 1:25 AM, Justin Fagnani <[EMAIL PROTECTED]> wrote: > > > On Mon, Apr 28, 2008 at 2:10 PM, Nicolas E. Lara G. <[EMAIL PROTECTED]> > wrote: > > I didn't understand your point here. When is the data incomplete? > > An example would be grouping people by age and averaging income, what should > the values of the name field be? None might make sense at first, as Honza > suggests, but what happens to methods that depend on name? The whole point > of returning models is to have access to the methods and other class > metadata, but if data is missing or not meaningful, then those methods might > not be useful. >
In this case: should we actually return the actual objects? If a values modifier is involved the expected behavior is to receive a list of dicts. IMO, we should not allow aggregates to override this behavior. Also, having some value for the fields wouldn't make sense since we cannot ensure there is a unique value for a given field for that group (unless it is specified in values, in which case it would automatically appear). I like the idea of having a QuerySet for retrieving the grouped objects. This can be done simply by having something like: {'objects': <QuerySet object>} > > > I dont see the problem in averaging an integerField (probably in > > averaging a CharField, but IMHO this kind of invalid values should > > make the whole query fail). > > > > > > > > The problem with averaging an IntegerField is that the result is unlikely to > be an integer, yet parts of the model might assume that it is. At the very > least AggregateModels in this situation are unable to be validated, saved or > deleted, and it's possible that other methods don't work, so either they > shouldn't be models at all, or we need to disable lots of things and issue > big, big warnings. > or they can be a list of Models only when no 'values' is specified. > > > > I aggre. An advantage (which I think might also be a double edge > > sword) of the string function names is the possibility to fallback to > > a standard convertion to SQL when no function is defined. > > I'm not sure how wise this is. Considering the variation of available > functions, and their different behaviors, just passing the function name > straight into SQL could easily encourage non-portable queries. I know some > users will want DB specific functions, but like extras, it should probably > be clearly advanced functionality. > I am not sure either. I see the problems it might bring. > Ideally expressions.py should be import * friendly > > > > > > In addition, some cases have special requirements and dealing with them > in a > > > class is easy. > > > > > > > I can't think of a requirement that can't be dealt with in a method > > also... got an example? > > > > > Count() is an easy example. First, it takes an extra kwarg, 'distinct', and > changes the output of as_sql() if set. Then it also has to do a special case > in relabel_aliases() and whatever method passes column names to > query.setup_joins() for COUNT(*) > This could all be handled in a count method. Still I see that using classes poses and advantage. > > Cheers, > Justin > > > > > > Regards, -- Nicolas Lara --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---