cubicweb #643087 stop pretending we're offering a sql dbapi [resolved]

Comments

• 2010/02/09 11:08

  Side note : the point of the dichotomy of execute / fetchXXX in dbapi is that not all requests have the effect of returning data (only SELECT does), so this design allows to have a single return prototype and not having to check for None on the execute return value.

  A nice extension found in pyodbc is having cursor.execute return the cursor, allowing cursor.execute('...').fetchall(). Another nice one is having the cursor being an iterable on the current result set, allowing for row in cursor.execute(...).

  I'm overall uneasy about cnx.execute() -> rset as I feel this could prevent us from using some generator-based optimisations which could be available in some db backend by forcing a fetchall() which could be a costly operation (and potentially a harmful one if the rset is huge and causes an OutOfMemory exception or a kill by the kernel).
  • 2010/02/09 11:15, written by mailbot

    cnx.execute() -> rset
    

    is currently what we have, hidden behind a noop cursor implemetation.
    

    But I agree we should kept in mind such later optimization.
    
• 2013/06/03 15:40, written by pydavid

  I would support a pure drop of this DBAPI. That would be replace by cleaned up In memory Object, REST interface and simple RQL server over zmq.
• 2014/07/02 10:13, written by jcristau

  should we treat this as identical to #3933480?