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 #1054035 javascript: kill formContents?
- cubicweb #1697862 ORDERBY SUM(C) seems to cancel GROUPBY
- cubicweb #1381203 [formfields] not all fields delegate form analysis to their widget
- cubicweb #344874 shouldn't we replace unsafe_execute/execute on session by execute/safe_execute
- cubicweb #246942 supporting aggregates in SET queries
[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?