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 sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
