This is something I attempted once to do over a small GET wrapper by adding __not; any __not query would be passed to exclude(). Would that be a solution to the problem?
J. Leclanche / Adys On Tue, Oct 20, 2009 at 6:31 PM, Michael P. Jung <[email protected]> wrote: > > rm> exclude(x=1).exclude(y=2) translates to NOT (x=1) AND NOT (y=2) > > So why do we have __gt, __ge, __lt, __le then? It would be as simple to > have only __le and get rid of the rest as it can easily expressed using > exclude and filter. I know, it's picky, but you get my point. > > I don't see why all comparison operators are supported except for one: > > http://dev.mysql.com/doc/refman/5.1/en/comparison-operators.html > http://www.postgresql.org/docs/8.3/static/functions-comparison.html > > mp> (...) Since __isnull is ment to be obsolete, according to Russ > mp> Magee, it'd be really ugly having to rewrite these queryies to a > mp> chain of excludes. > > rm> I didn't say they were obsolete - I said that they existed for > rm> historical reasons. I don't think there's been any formal decision to > rm> deprecate these operators. > > Whops. Sorry for quoting you wrong. I thought you ment it was supposed > to be obsolete even though it hasn't been marked as such yet. > > > --mp > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
