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.
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.
> 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.
With this we
> wouldn't need to wrap every aggregate method in a python class that
> translates roughly the same way and we could take advantage of the
> direct usage of the DB defined aggregate functions.
Defining most functions is quite easy. Here's Max:
class Max(Aggregate):
_func = 'MAX'
I'm sure we can get all the standard functions in there.
> Also with the A
> syntax you would do only one import instead of one for each function.
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(*)
Cheers,
Justin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
