An empty IN() list is a syntax error for most SQL engines, so it might be better to generate no clause at all, though I don't know how that would play with surrounding ANDs, ORs and etc.
In the final analysis, you're the one best to judge on how the ORM will feed in IN() items. If it won't break ORM by doing a more-or-less literal translation of the clause, then +1 from me. On 4/11/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > i vote no interpretation at all...if you want IN with one element, thats > what youll get. no elements, ditto. > also the bind param + etc ticket is #476. its got svilens artwork > attached to it which i'd like to refine into a patch + unit test (but > without the vis4check module/visitor thing...too complex..would rather have > it just take ClauseElements unconditionally for now). > On Apr 11, 2007, at 4:58 PM, Rick Morrison wrote: > > I think the singleton to equals is fine, but I'd be equally OK with a "no > surprises" policy. I think the empty-list optimization should go, tho. > > > > On 4/11/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > > > > > > On Apr 11, 2007, at 3:22 PM, Ants Aasma wrote: > > > > > > > > I'd say this is a definite bug. The semantics of col.in_(list) should > > > be column value equals any of the values in the list. For an empty > > > list it should be a constant false, because no value exists in an > > > empty list, not even an missing value (null). What makes it a bit > > > tricky is the fact that for null values the result should actually > > > also be null. When straight .in_() is used it doesn't really matter, > > > but when the negation is used then it starts to matter. That's because > > > not_(col.in_()) should be the equivalent of COL IS NOT NULL. I think > > > the best way would be to compile it to COL != COL, it has the correct > > > behaviour when negated as well as not negated. Diff follows: > > > Index: lib/sqlalchemy/sql.py > > > =================================================================== > > > --- lib/sqlalchemy/sql.py (revision 2494) > > > +++ lib/sqlalchemy/sql.py (working copy) > > > @@ -895,5 +895,5 @@ > > > def in_(self, *other): > > > if len(other) == 0: > > > - return self.__eq__(None) > > > + return self.__ne__(self) > > > elif len(other) == 1 and not hasattr(other[0], > > > '_selectable'): > > > return self.__eq__(other[0]) > > > > > > > right well thats one way to look at it, i.e. that we should interpret > > the meaning of "IN ()" in some special way. the current behavior is > > based upon my going with that approach a couple of years ago (and > > getting it wrong...suprise). > > > > but why dont we want to just have it compile just as it says - to "IN > > ()" on the database side ? im not sure if trying to guess what the > > user means here is the best approach (refuse the temptation to guess...) > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
