On sqlite-users@mailinglists.sqlite.org, Randall Smith <rsm...@qti.qualcomm.com> wrote:
>Date: Fri, 23 Aug 2019 13:16:18 +0100 >From: Simon Slavin <slav...@bigfraud.org<mailto:slav...@bigfraud.org>> >>I have no connection with this extension to the APSW Python SQLite >>wrapper, I just saw a pointer to it. The latest commit is around >>nine months ago. Perhaps someone who is familiar with Python >>libraries might highlight anything this does new or unusually well. >><https://github.com/plasticityai/supersqlite> >I have looked at this on and off for Python effort I have been >working on. I think one big claim to fame for this wrapper is better >and more predictable transaction handling. The "normal" python >SQLite library is really weird about transactions, and tends to >introduce its own transaction-related operations behind the scenes, >so as a user you're never 100% sure what's going on or whether your >own transaction management is doing what you expect. I find this >really annoying since one wants transaction handling to very simple >and predictable so that the right thing happens under all >circumstances. >I, too, would be interested to hear from people who have real >experience with it. I took a brief look and I cannot see why one would want to use BOTH the standard pysqlite wrapper (which is included with the default distribution of Python) AND APSW at the same time, nor can I see anything that this does that one could not do by simply using the standard pysqlite and standard APSW, thus avoiding all the bother. As soon as I found out about APSW I stopped using pysqlite for exactly the reason that you say -- its transaction handling is completely buggered (though you can get around that by always opening a database with the isolation_level=None keyword to disable Esmeralda's magic -- Esmeralda of course referring to Naomi Hogan's character in the 1964 series Bewitched that was always casting spells that didn't come out quite as expected). Plus, of course, the advantage that APSW is still being actively maintained by Roger Binns, who is active here as well; and, that you can build it as an extension that includes SQLite3 so there is no symbol pollution and no dependency on the vagaries of using the system sqlite3 shared library. About the only thing that pysqlite has that APSW does not is access to the converterss and adapters plugins, and the "Row" object. These things can, however, be fixed quite easily since you can write your own code to implement these things (as I have done, far surpassing the ability of pysqlite to do these things) using nothing more than the builtin capablilites of APSW (the exechook and rowhook) and doing a little class wrapping. (My Row object inherits from the builtin dict but allows access as attributes r.field, dictionary r['field'], or tuple r[2] and implements the pickle protocol as well). APSW does not expose the sessions, changeset, or rbu interfaces of SQLite3 to Python but then I have never needed those anyway, and if the need came I suppose I could always modify APSW to build itself to expose those symbols so they could be accessed by ctypes, since a .pyd is nothing more than a shared library anyway. Plus, of course, APSW is very well documented. I do not think that applies to either pysqlite or supersqlite. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
