On 10/14/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Hey Russell, > > On Sat, 2006-10-14 at 10:54 +0800, Russell Keith-Magee wrote: > > On 10/12/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > > > > Russell Keith-Magee: > > > > Sorry - I'm confused; Are you agreeing with the proposed change, or > > > > saying it contradicts your expectations? (I think you are agreeing - I > > > > just want to make sure) > > > > > > My highest preference is to make __exact=None behave like WHERE > > > xxx=NULL, i.e. returning an empty set, against current behaviour > > > *and* against your proposal. > > > > Ah - I missed the subtle difference you were advocating (=NULL vs IS > > NULL). I agree completely; committed as r3902. > > I really don't like this particular portion of the change. Using "= > NULL" is a poor construction: legal, but pointless. Nothing should be > equal to NULL, ever (except in Oracle, which likes to compare empty > strings as being equal to NULL, but it's broken in that respect). NULL > is not even equal to itself.
Hence the documentation to that effect. No, it isn't a particularly useful expression, but it does have at least one use case (discussed below). I wasn't aware of the Oracle issue; but that strikes me as a problem that should be fixed at the backend level, rather than as a reason to exclude a feature. > So doesn't this defeat the purpose of the exercise now? Using > __exact=None is now a synonym for "please don't ever return anything > (except on Oracle)" whereas I thought your were shooting for "where this > field is NULL". The use case that started this for me is in the regression test - a related manager for an unsaved object. In this case, 'don't ever return anything' is _exactly_ the right response, because nothing can be related to the unsaved object. Mapping __exact=None to _isnull=True will give effectively the same results, but via a 'return everything with a primary key value of NULL - which is nothing' interpretation of the problem. However, as you noted earlier, this second approach is redundant given the existence of _isnull. It also hides a path to the expression of some valid (albiet edge case) SQL. The interpretation suggested by Michael struck me as a good way to avoid the redundancy, fix the bug I found, expose a small corner of legal SQL statements, and ultimately required less code to implement. The biggest problem I could see was the potential for '__exact=None doesn't mean what you think it does' amongst newcomers. For me, the best solution to this problem is documentation. 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 [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 -~----------~----~----~----~------~----~------~--~---
