On Tue, Mar 8, 2011 at 9:35 PM, bendavis78 <bendavi...@gmail.com> wrote: > I'd like to start a discussion on this since russelm closed the > issue. There are a few other people that believe the issue should be > left open. I've been using this patch for nearly two years, and have > found it to be useful in several different cases. I disagree that > the .raw() functionality is a sufficient alternative, as it is not > possible to modify an existing queryset using .raw(). For example, > if I have a function that accepts a queryset, I want to be able to > modify that queryset by giving it a extra info for the JOIN and SELECT > clauses.
.extra() was a kludge that existed because .raw() didn't. Frankly, I'm considering deprecating and removing .extra() entirely: I've rarely seen a case where using it didn't come back to cause problems in the future. I'm certainly going to be a strong -1 on adding any more "features" to .extra(). Remember, Django's ORM tries to hit an 80-90% point, but then you're *expected* to fall back to raw SQL past that point. Falling back to raw SQL when it's easier is a feature, not a bug. Jacob -- 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.
