Even if it is a kludge, it still accomplishes something that .raw() cannot (as Dan put forth). I think deprecating it in favor of raw doesn't make much sense, since they are two different things. On Mar 9, 2011 4:06 PM, "Dan Watson" <dcwat...@gmail.com> wrote: > > > On Tuesday, March 8, 2011 6:16:26 PM UTC-5, Russell Keith-Magee wrote: >> >> On Wed, Mar 9, 2011 at 7:09 AM, Jacob Kaplan-Moss <ja...@jacobian.org> >> wrote: >> > On Tue, Mar 8, 2011 at 9:35 PM, bendavis78 <benda...@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: >> >> Yes. Yes Yes Yes. Yes. Oh, and Yes. +1. >> >> > 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(). >> >> Agreed. From an engineering perspective, extra() is the single most >> fragile part of the ORM. Dumping extra would make me extraordinarily >> happy. >> > It's also incredibly useful for certain situations. Two that come > immediately to mind are augmenting objects returned with an extra field via > custom SQL (a subselect for instance), and using custom SQL (e.g. to_tsquery > for full-text searches in Postgres) in the WHERE clause. Both *could* be > accomplished using .raw() if you don't mind giving up .filter(), > .order_by(), etc. But it would be a shame to throw out everything a queryset > gives you just because you need hooks into the SQL it generates. > > If you're seriously considering deprecating .extra(), I think it would be > beneficial to put together some use cases (such as those above) that could
> be covered in a less-fragile way. > > Dan > >> > > -- > 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. > -- 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.
