Re: [Sqlalchemy-tickets] [sqlalchemy] #1835: Better in filter handling

[sqlalchemy <mi...@zz...>]

#1835: Better in filter handling
---------------------------------+------------------------------------------
    Reporter:  guest             |       Owner:  paj                   
        Type:  enhancement       |      Status:  closed                
    Priority:  medium            |   Milestone:                        
   Component:  sql               |    Severity:  no triage selected yet
  Resolution:  worksforme        |    Keywords:                        
Status_field:  completed/closed  |  
---------------------------------+------------------------------------------
Changes (by zzzeek):

  * status:  new => closed
  * resolution:  => worksforme
  * component:  access => sql
  * status_field:  awaiting triage => completed/closed


Comment:

 Don't you think it would be a surprise, to say the least, if someone said
 `in_()`, and suddenly a new "CREATE TEMP TABLE" and a bunch of INSERT
 statements were generated ?   How come the database's own IN operator
 doesn't do this ?

 The various workarounds for large INs mentioned in that article and others
 are perfectly fine for users to implement themselves, but none are
 appropriate in any way to be embedded in our own `in_()` construct.

 It's not a given in any case that using plain IN is inefficient.  An
 application that uses it for small batches of parameters will have no
 issues.   The database's caching of query plans will simply cache a
 handful of statements corresponding to each size of IN rather than one.
 Its up to the developer to decide if he or she wants to replace the usage
 of IN with a different scheme, not SQLAlchemy's.

-- 
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1835#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python