On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > What would the new (QuerySet) world order look like > ---------------------------------------------------- > What I propose to do is to split out the SQL construction from the body > of QuerySet and make it into a separate class. This class (let's call it > Query, for simplicity) would end up being a "query" attribute on > QuerySets and it's __str__ function would return the appropriate SQL > statement.
Broadly speaking, +1. When I last gave serious thought to aggregates, I was starting to have similar ideas on the need for a QuerySet refactor. Nice to know I'm not completely out on my own. Of course, the devil is in the detail, and there are some interesting edge cases where WHERE, HAVING and GROUP BY intersect, but if you're willing/able to come up with a first draft, I'm happy to throw my weight into poking holes in it. :-) > Things I think become easier this way > ------------------------------------- > - aggregates and other computed output columns > - custom fragments in portions of a query (as opposed to writing > a whole query for the database) > - adding new query types (GIS?) > - different database syntax (LIMIT/OFFSET in both MS SQL Server > and Oracle) > > I don't know of any announced plans/wishes that affect QuerySets that > would become more difficult under this change, so please sing out if you > know of any. That's a pretty good list. There might be a few others, but these are the big ones I am aware of. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
