> That was my thinking exactly. I think the cognitive dissonance
> involved in height__avg='average_height' is much greater than that in
> ({'average_height': 'height__avg}). Sure, it's new ORM syntax but it's
> also a new ORM feature. Overloading the existing syntax to do
> something that's actually quite different feels really strange to me.
Regarding this, I believe an option would be to use the reverse syntax:
aggregate(alias='field__function')
because it mimics what we normally do when assigning in code.
or simply aggregate('field__function') and have the standard alias be
the same as the requested aggregate (it would be 'field__function')
I still prefer this approach over the lookup objects. But this is
probably because i've been thinking of aggregates with the filter-like
syntax for a while and I became fond of it. Anyway I do think the
lookup object syntax is a very good approach, so here are some
considerations:
Extending seems easy, but is it? (in practice). The way I see to
extend this is to create custom classes (like Max, Avg, etc). this
classes would have a __init__ function that receives 2 parameters:
self, of course, and the field name. The newly defined class should,
then, call something like get_column_name('field') to be able to
translate itself into SQL. Pleas don't furiously reply there might be
other ways to do it, I know there are, this is just one of the ways I
could come up from the top of my head to ilustrate what I mean... A
proposition on this follows...
Though the objective syntax mimics Q objects, when using Q objects you
have one class, Q, that is used for all the queries. Having multiple
classes seems confusing. I would propose to have a single class (A?)
to do the queries. So you could do something like:
aggregate(height=A('max', 'height'), av_friend_age=A('avg', 'friend__age'))
This way A could receive the name of the function (or the actuall
function object) and the field to which it will be applied. A good
thing that could come from this is that extending (adding a new
function, or set of functions) would be really easy because, since the
heavy lifting would be done by A which would already be part of the
framework, the new function only needs to define how it transkates to
SQL given the column to which would be applied. Having the first
parameter be class/classname instead of function/function name is also
an option. This would allow us to add members to the class so that A
can act differentely. An example of this would be using a class that
has the 'alias_prefix' attribute to define what comes before the field
name in the default alias (A alias function could also be available to
receive the fieldname and return the alias).
class Custom:
alias_prefix = 'my_aggregate'
def as_sql(self, column):
return 'CUSTOM(%s)' % column
class WierdMax(Max):
def as_sql(self, column):
return super(Max, self).as_sql(column) - 10
so
aggregate(A('custom', 'height'), wierd=A('wierdmax', 'friend__age'))
would result in something like:
{'my_aggregate__hieght': 324, 'wierdmax__friend_age': 17}
I don't like the automatic lowercasing... Its very too much magic, but
I found the camel case quiet ugly...
Any thoughs?
--
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
-~----------~----~----~----~------~----~------~--~---
