On Fri, Jun 24, 2011 at 11:54 PM, stan <stanislas.gue...@gmail.com> wrote: > This topic is discussed on the Ticket #11305 : > https://code.djangoproject.com/ticket/11305 > > Like many folks, I am hit by the scenario where a relative simple > query become a design decision because my «boss» asked me : "Hey Stan, > can you add me a column with the number of valid items in each > category ?". > > Here we have two bad solutions : > > 1. Move the nice orm-ed query in a db-dependant, pain-in-the-arse- > to[write|maintain] raw sql one ; > 2. Write a MonkeyCount() that take some arbitrary sql code with > hardcoded tablename.
I wouldn't be so quick to discard the raw SQL option. It's easy to fall in love with an ORM, but it's also important to recognize when the relationship needs to end. ORM's are really good at simple cases, but they fail really badly (or, at least, in unpredictable ways) the more complex your queries become. I have exactly zero interest in trying to make Django's ORM able to express 100% of all possible SQL queries. We already have a language that can express 100% of SQL queries -- it's called SQL. And it works really well. > I have picked the second one but I am not really happy with it. I am > in a early stage and I don't want to have a surprise of a database > incompatible patch when I will deploy. > And being lazy I also don't want to build a pre-production server > right now just to test that. > > Ok, I know I am lazy and this solution is just fine. But a lot of > people lose a small amount of time because of this gap. > > As Russellm said 2 years ago : "the Django core should be exposing the > tools that make it possible for end-users to write their own complex > aggregates". > > But I do not fully agree with this request beeing specific. > > Maybe we could implement something that cover all the aggregate > functions and all conditional cases ? Trying to cover *every* aggregate and *every* conditional case is an impossible goal. However, trying to represent *common* aggregates and *common* conditionals is another thing entirely, and is certainly worth exploring. > In terms of design, is something like that absolutely stupid ? : > > Aggregate(lookup, only=None, **kwargs) > > By example: > > queryset.aggregate( > expensive_house=Count(house__price, > only=(Q(house__price__gt=41000), Q(house__price__lt=43000))), > ... > ) Ok, so that's you're syntax proposal. Now show me the SQL that this translates into. In particular, keep in mind that you're doing joins in your Q clauses -- how does that get rolled out into SQL? This isn't a trivial area you're stepping into -- it's complex code, specifically because of all the edge cases that it needs to cover. I'm happy to entertain design proposals, but they need to contain two parts: 1) A clear and unambiguous syntax for users 2) A clear and unambiguous interpretation for SQL. To *really* capture my interest, they also need to be accompanied with at least a first-pass attempt at an implementation. 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 django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
