Thanks for the reply, Russell. It's obviously a lot more complex and detailed than simply adding a min() where count() is. :)
A couple thoughts... > 4 - If you search the archives (user and developer), you will find several > discussions on aggregate functions. group_by() and having() (or > pre-magic-removal analogs thereof) have been rejected previously on the > grounds that the Django ORM is not intended to be 'SQL with a different > syntax'. Any proposal for group_by/having will have to be logical from a > Django ORM point of view, and not presuppose/require knowledge of how SQL > formulates queries. Here's a quote from you in another thread about this: [quote] It was made clear to me then that 'SQL does it like X, so lets add X to Django' wouldn't win me any points. Django's ORM isn't about finding a way of representing SQL as Python - it's about getting a consistent, expressive object model, that just happens to be backed by a SQL database. Keep in mind that it could just as well be backed by an object database, or some other persistent store. What will happen to SQL notation if SQL isn't available? [endquote] Source: http://groups.google.com/group/django-developers/browse_frm/thread/245a37912cf8d4e3/64473bd51d00ff84#64473bd51d00ff84 I think that puts more perspective on the idea. Considering that the backend might be something other than a relational database at some point and should still use the same Django database API to access that data does mean a complete separation of SQL-like ideas and notation. Before I had read that my thoughts were that if the user knows they need calculated averages and sums, one could assume they already know enough about their data and how it's stored to let SQL bleed into the ORM to some degree. But now I think the case is well made. But isn't it also dangerous to code (or not code) for future cases that may or may never come? If a non-relational database backend isn't anywhere on the current horizon, why not code aggregates and groups to the current usage and break BC when they arrive, possibly at the Django 2.0 transition? Just a devils advocate thought. > However, here are some issues to consider: Yes, lots of issues to consider. Lesson learned: Search the archives before proposing an idea. :) But as I look back, there have been many great discussions. It gives me more faith in Django and the Django developers that they hold their code and features in such high regard. Cheers! Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
