Issue1682864

CPython 2.5 has new package in standard library 'sqlite3'. Here is compatibility module '_sqlite3' implementation using 'javasqlite' [http://www.ch-werner.de/javasqlite/].

Deferred to 2.5.1

The SQLiteJDBC project came out shortly after this patch was created: http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC

The javasqlite it uses can be painful to install because it requires 
compiling its JNI linkages

SQLiteJDBC however works out of the box, it includes pre-compiled shims 
for the popular platforms and falls back to the slower NestedVM 
emulation on other platforms. It also seems well maintained, however 
javasqlite looks to still be maintained too

I would love to see this module tweaked to use SQLiteJDBC instead. This 
will require some work however as its api is different from javasqlite's

Should revisit, among other things this would support https://bitbucket.org/jython/jython/pull-request/14/for-discussion-changes-to-support-ipython/

Some things to explore here:

* sqlitejava is clearly closer to the underlying SQLite, as a simple wrapper; it's also what Michael Dubner contributed a Python wrapper for.

* Xerial seems to be much more supported, and doesn't have native dependencies for us to consider.

It's pretty clear we need to go with the Xerial solution - we don't have the engineering resources to manage native dependencies.

Note that custom functions (UDFs) can be done with Xerial, https://bitbucket.org/xerial/sqlite-jdbc/src/975459c6e053b850404c04bc4bc3f5e52dcd8686/src/test/java/org/sqlite/UDFTest.java?at=default#cl-47

Likewise, there appears to be support for callback functions as well, by perusing some of the commits. I wasn't able to find any real docs however, so we will have to look at source code to go past JDBC.

Probably the best way to do this is develop outside of Jython's development process, much like jyjdbc or Clamp

There's another option, albeit a distant one for providing sqlite3 -- implementing a cffi backend and providing cffi, which is something we'd like to do anyway. Then we could use PyPy's _sqlite3 impl:

https://bitbucket.org/pypy/pypy/src/8bc429151c06505db6f2393fcd9f35a91971c510/lib_pypy/_sqlite3.py?at=default

2.7.1 or later

In msg8757, I proposed implementing outside of Jython's development process. However, given that we are planning to move to a 6 month release cycle, this doesn't seem to be so important - when the implementation of sqlite3 is done, we can make it part of the next 2.7.x release.

I also examined Xerial's support for what is required. As far as I can tell, all necessary functionality is implemented, including extension loading. Testing varies in the Python 2.7 test suite - there's no testing at all for extensions (see https://github.com/python/cpython/commit/b53996dead8c6a602d3f4f6c73bdd4573d0e49ef), but most other testing seems to be more than adequate.

Moving to 2.7.2 (or later)

Did someone take a look at this repository?
https://github.com/anthonyhendrickson/jython-sqlite3
It's only 3 weeks old, but might be promising.

Also. I was able to do some basic stuff with sqlite3 on Linux using JyNI. Importing works out of the box, creating, a db, cursor, execute simple sql-commands works. Some unittests crash JVM with a segfault (5 or so). If I remove these crashing tests, about 70% of the remaining unittests succeed. So, making this bulletproof would require some serious work. Maybe it would be more valuable to make cffi bulletproof and go the PyPy-path. As of this writing I wouldn't want to go through the failing tests to clean up support. However if one of them should turn out to be crucial for some actual use-case, e.g. to support some dependent framework, let me know: Then I will fix it with priority.

I like https://github.com/anthonyhendrickson/jython-sqlite3 in terms of its packaging, but it doesn't port the sqlite3 module. Instead it makes sqlite3 available as a DBI2 compatible package. So separate goals.

Using JyNI could be a good alternative, but I think this port would be straightforward to Jython. Just requires a bit of time - I'm estimating a solid week of work.