Re: [sqlite] SuperSQLite: a supercharged Python SQLite library

[Keith Medcalf]

On sqlite-users@mailinglists.sqlite.org, Randall Smith 
 wrote:

>Date: Fri, 23 Aug 2019 13:16:18 +0100

>From: Simon Slavin 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.

>>

>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

[sqlite] SuperSQLite: a supercharged Python SQLite library

[Randall Smith]

Date: Fri, 23 Aug 2019 13:16:18 +0100

From: Simon Slavin 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.







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.



Randall Smith


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SuperSQLite: a supercharged Python SQLite library

[Simon Slavin]

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.



" A feature-packed Python package and for utilizing SQLite in Python by 
Plasticity. It is intended to be a drop-in replacement to Python's built-in 
SQLite API, but without any limitations. It offers unique features like remote 
streaming over HTTP and bundling of extensions like JSON, R-Trees (geospatial 
indexing), and Full Text Search. SuperSQLite is also packaged with pre-compiled 
native binaries for SQLite and all of its extensions for nearly every platform 
as to avoid any C/C++ compiler errors during install. "
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users