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
-~----------~----~----~----~------~----~------~--~---
