On Thu, 28 Jan 2016 16:47:40 -0500 Jim Callahan <jim.callahan.orlando at gmail.com> wrote:
> I am hopeful this new JDBC based interface will provide as > satisfactory high level channel between SQLite3 and Python. As someone who's written a couple of OO DBMS libraries and uses the Python SQLIte module, I wonder what you're hoping to see. What example do you have in mind for OO functionality not already there? ODBC was created for one reason only: to define a binary interface to DBMS client libraries. Afaik the same is true for JDBC. That interface-to-a-library property has two downsides: 1. Configuration complexity. With SQLite, there is no configuration file. Most of the features of a connection -- server, port, username, password, etc. -- don't apply. When a connection fails, it takes some expertise to tease out whether the problem lies in the ODBC configuration, the client library, the server, or the network. With JBDC you have still more: the added complexity of Java setup. 2. Opacity. ODBC is near the top of my list for vague error messages. Favorite: "General ODBC error". If I ever meet General ODBC, I'm going to give him a piece of my mind, if I have any left. The second is terribly important. Take error handling. Instead of getting back, say, SQLITE_BUSY, and RTFM, you get an ODBC error and then maybe, with a little more work, the underlying status code and message. And you're *still* not done, because did I mention the ODBC driver is opaque? Your ODBC call uses the native library in unspecified, undocumented ways. When you get the native error status, you then have to reason about what the ODBC driver must have done, and from there back to what you need to do. It's a whole layer of black magic and obfuscation that only lengthens your day. And it's not just errors. How do you map the ODBC API onto SQLite's API? (I've never seen an ODBC driver document the relationship of the ODBC functions to the native ones.) What to do with sqlite3_exec or sqlite3_blob_open? If you know the SQLite API, you'll spend quite a bit of time discovering how it's been mapped onto the ODBC API. And when you're done, you'll discover pieces missing. You already have one layer of mediation in the Python sqlite module. That module is thankfully a pretty thin veneer over the C API, and the errors it produces can be straighforwardly traced to the C function it exposes. You have the convenience of using the connection as a context manager, of row objects (although dict would have been better), of fetchall. What sort of OO garnish would you add? --jkl
