On Apr 12, 6:37 pm, svilen <[EMAIL PROTECTED]> wrote: > how about whatever.in() -> (whatever and False) > maybe problem with Null then? (null and false) gives false, so not(null and false) is true. This means that not_(col.in_()) returns all rows, while not_(col.in_(nonexistantvalue)) returns all that are not null. One other option would be to return _BooleanExpression(self._compare_self(), null(), '=', negate='IS NOT'). The only problem is and edge case when someone uses an in_ with an comparison expression like so: col.in_() == False. This should return a list of non-null entries to be consistent, but instead returns an empty list. IMHO the expected behaviour is quite clear in all cases - just use the standard SQL idioms and relational idioms, comparison with null is null and no value is in an empty list. The CASE WHEN expr IS null THEN null ELSE false END expresses it quite nicely. The comparison is there to satisfy Oracle Firebird and Mssql, which don't like plain case expressions in where. I'd say that it makes the API conceptually simpler by removing a special case at the expense of some minor (compared to some other constructs that SA ORM emits) confusion when deciphering produced SQL statements.
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
