Re: More efficient negative lookups
One small related point. The admin could benefit from a way of doing negative lookups within the lookup syntax itself. Currently there is no way to construct an exclude filter change list views in the URL. i.e. If I am writing a custom filterspec or anything else that results in a URL for a changelist page then I can do: /admin/app/model/?model__id__exact=4 but I can't reverse the logic. There might be better ways to allow this than just adding a negative version of every lookup but I thought I'd throw another use case into the ring. Andy -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: More efficient negative lookups
On Thu, Oct 28, 2010 at 6:59 AM, George Vilches wrote: > > > On Oct 27, 5:55 pm, Jacob Kaplan-Moss wrote: >> On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: >> > I'm inclined to say we do the former -- restore the "ne" lookup type >> > -- because it's a quick fix, and ask somebody to write up a patch for >> > the latter. Does anybody have strong opinions against this? If not, I >> > can restore the "ne" lookup type. >> >> Sounds like a good plan to me (especially making simple excludes faster). >> >> However, just for the record I think the reason we decided to remove >> __ne is the first place was that its existence introduces a weird >> inconsistency with regard to other lookup types. That is, if there's a >> "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down >> that path lies madness so I'm +0 on bringing back "ne" with the >> proviso that we agree it's not the first step down a slippery slope >> towards "nistartswith" and friends. > > I know it's been a little while since I've made any major ORM > contributions, but I'd say -0 on __ne, and +1 on making exclude > generate better code. Django's worked far too hard on making things > consistent as possible to let like this slip by just because we don't > want to muddy our hands with a little harder work in the exclude() > code. I agree. We should certainly fix the behavior of exclude(), but reintroducing __ne feels like the start of a slippery slope to me. Conceptually, I'm -1 on reintroducing __ne. In the interests of practicality, I'd be willing to reconsider if it turns out that fixing exclude() is prohibitively complex. However, it seems premature to reintroduce __ne as a stop-gap measure before anyone has taken a serious look at what is involved with fixing exclude(). We still have almost 3 months until the freeze for 1.3; that should be plenty of time to investigate exactly how much work would be involved in fixing this bug properly. 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-develop...@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.
Re: More efficient negative lookups
On Oct 27, 2010, at 5:55 PM, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: >> I'm inclined to say we do the former -- restore the "ne" lookup type >> -- because it's a quick fix, and ask somebody to write up a patch for >> the latter. Does anybody have strong opinions against this? If not, I >> can restore the "ne" lookup type. > > Sounds like a good plan to me (especially making simple excludes faster). > > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down > that path lies madness so I'm +0 on bringing back "ne" with the > proviso that we agree it's not the first step down a slippery slope > towards "nistartswith" and friends. I know it's been a little while since I've made any major ORM contributions, but I'd say -0 on __ne, and +1 on making exclude generate better code. Django's worked far too hard on making things consistent as possible to let like this slip by just because we don't want to muddy our hands with a little harder work in the exclude() code. So many other tickets have been stuck in DDN/Accepted forever because the area of code is harder to review, it's not like it's an unknown state in the project. :) I'd even be willing to throw my hat in the ring to contribute towards an .exclude()-based solution if someone else doesn't step forward, but I know I won't be touching it until a few days pass. George -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: More efficient negative lookups
On Oct 27, 5:55 pm, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: > > I'm inclined to say we do the former -- restore the "ne" lookup type > > -- because it's a quick fix, and ask somebody to write up a patch for > > the latter. Does anybody have strong opinions against this? If not, I > > can restore the "ne" lookup type. > > Sounds like a good plan to me (especially making simple excludes faster). > > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down > that path lies madness so I'm +0 on bringing back "ne" with the > proviso that we agree it's not the first step down a slippery slope > towards "nistartswith" and friends. I know it's been a little while since I've made any major ORM contributions, but I'd say -0 on __ne, and +1 on making exclude generate better code. Django's worked far too hard on making things consistent as possible to let like this slip by just because we don't want to muddy our hands with a little harder work in the exclude() code. So many other tickets have been stuck in DDN/Accepted forever because the area of code is harder to review, it's not like it's an unknown state in the project. :) I'd even be willing to throw my hat in the ring to contribute towards an .exclude()-based solution if someone else doesn't step forward, but I know I won't be touching it until a few days pass. George -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: More efficient negative lookups
On Wed, Oct 27, 2010 at 4:55 PM, Jacob Kaplan-Moss wrote: > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down > that path lies madness so I'm +0 on bringing back "ne" with the > proviso that we agree it's not the first step down a slippery slope > towards "nistartswith" and friends. Totally agree we should set clear expectations that "ne" does not mean we'll be getting nistartswith or any other negative lookup -- good call in bringing that up. This should be treated as a special case for a common case. Adrian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: More efficient negative lookups
On Wed, Oct 27, 2010 at 5:55 PM, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: >> I'm inclined to say we do the former -- restore the "ne" lookup type >> -- because it's a quick fix, and ask somebody to write up a patch for >> the latter. Does anybody have strong opinions against this? If not, I >> can restore the "ne" lookup type. > > Sounds like a good plan to me (especially making simple excludes faster). > > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down > that path lies madness so I'm +0 on bringing back "ne" with the > proviso that we agree it's not the first step down a slippery slope > towards "nistartswith" and friends. > > 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-develop...@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. > > I'd be -0.5 (let's see how pusillanimous I can be!) on introducing __ne, but +1 on fixing the internals to generate proper not equal comparisons. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: More efficient negative lookups
On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: > I'm inclined to say we do the former -- restore the "ne" lookup type > -- because it's a quick fix, and ask somebody to write up a patch for > the latter. Does anybody have strong opinions against this? If not, I > can restore the "ne" lookup type. Sounds like a good plan to me (especially making simple excludes faster). However, just for the record I think the reason we decided to remove __ne is the first place was that its existence introduces a weird inconsistency with regard to other lookup types. That is, if there's a "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down that path lies madness so I'm +0 on bringing back "ne" with the proviso that we agree it's not the first step down a slippery slope towards "nistartswith" and friends. 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-develop...@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.
