cubicweb #643087 stop pretending we're offering a sql dbapi [validation pending]
| |
| priority | normal |
|---|---|
| type | enhancement |
| done in | 3.21.0 |
| load | 0.500 |
| load left | 0.000 |
| closed by | <not specified> |
similar entities
- cubicweb #615294 reuse rql built through the use of facets
- cubicweb #1083245 unify cleanup-session-time / session-time
- TheCubicWebBook #569161 named string formatting in rql queries
- cubicweb #1568456 login parameter should be mandatory for cubicweb.dpapi.connect
- cubicweb #468093 refactor [contextual] components and global configuration
[see all]
Comments
-
2010/02/09 11:08
-
2010/02/09 11:15, written by mailbot
-
2013/06/03 15:40, written by pydavid
-
2014/07/02 10:13, written by jcristau
add commentSide 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).
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.
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.
should we treat this as identical to #3933480?