just my point of view: generatively, i would probably do .in_( somelist ), where somelist is a variable, and it will work fine until that list gets empty. If that happens frequently, okay, i'll know soon about it and fix it/avoid it, but if it's once in a blue moon, u'll get one more disappointed SA user ;0(. And if that list is a bindparam, it gets even harder to check/guess.
> On Apr 11, 2007, at 6:13 PM, Ants Aasma wrote: > > b) produce IN () SQL > > + 1:1 mapping between python and sql > > - most databases will give obscure errors, possibly far away from > > source of error > > well i dont think it would be a hard error to track down. the ORM > doesnt use in_() so if an in_() happens, its because a user used it > in their own code. > > > - different behaviour between databases > > it would raise an error on most but SA tries to support DB > idiosyncracies, like SQLite's accepting it > > > c) do a natural extension of SQL IN syntax > > + makes user code simpler in non negligible amount of cases > > agreed > > > + behaves the same in all databases > > agreed, as long as we know that saying "somecolumn != somecolumn" > is valid and produces False on all dbs (including > frequent-offenders firebird and ms-sql) ? (thats how you > interpreted IN (), right ?) > > > - some one could possibly expect different semantics > > yup, thats what im hoping to avoid. im still concerned we're just > "guessing" here, and when users are surprised, its SA's job (i.e. > mine, usually...) to then explain/justify > > but overall, i dont care much either way so leave my vote out of > this one. > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
