On Tue, Apr 29, 2008 at 12:49 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> Is it my understanding that aggregate would not return an actual
> object (from the original examples above).
>
> Also, in regards to HAVING support. Unless you plan to implement logic
> into .filter() which says "oh hey this is from an aggregate, using
> having" then this is a MUST. There's no other way you're going to be
> able to magically say "he wants having" for all cases.
>
The idea is to implement exactely that logic into filter.
> In fact, I'm still not sure (without explicit SQL methodology support,
> which I'm still confused as to why no one wants to implement) you will
> quite achieve this. I'm also not sure how count fits into field names.
> Does any database layer actually differ on count(field_name) vs
> count(1) vs count(*) when you are doing aggregation?
They do. count(*) and count(1) will count every element,
count(colum_name) will count those that are not null for the given
column name.
> MyModel.objects.filter(Q(tags__name='django') |
>
> Q(tags__name='aggregate')).aggregate(tags__count='matched_tags').filter(matched_tags=2)
>
>
> On Apr 29, 12:45 am, "Nicolas Lara" <[EMAIL PROTECTED]> wrote:
> > 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
>
>
> >
>
--
Nicolas Lara
Linux user #380134
Public key id: 0x152e7713 at http://keyserver.noreply.org/
# Anti-Spam e-mail addresses:
python -c "print '@'.join(['nicolaslara', '.'.join([x for x in
reversed( 'com|gmail'.split('|') )])])"
python -c "print '@'.join(['nicolas', '.'.join([x for x in reversed(
've|usb|labf|ac'.split('|') )])])"
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
