Change History

3.6.19-r1

Backwards incompatible change Fixed issue 72 where APSW wasn’t zero basing virtual table BestIndex() constraints returned as documented. If you have working BestIndex code then you need to update it for this release. Thanks to Lefteris for finding this issue.

Backwards incompatible change The complete() method has moved from Connection to apsw where it should have been all along. You should now call apsw.complete() instead. (It even had an example showing it to be part of the module and not a specific connection!)

There is now an interactive shell very similar to that provided by SQLite. You can embed it in your own program, inherit from it to provide more commands and output modes, or just run it like this:

$ python -c "import apsw ; apsw.main()"

Added the SQLITE_LIMIT_TRIGGER_DEPTH, SQLITE_OPEN_PRIVATECACHE and SQLITE_OPEN_SHAREDCACHE constants.

The setup.py file now has the various options available made applicable to appropriate commands only. Read the updated documentation.

You can now specify build --enable=stat2 to setup.py to enable advanced statistics gathering for query planning.

setup.py can automatically fetch the Asynchronous VFS extension for you. If the source is present when APSW is built then it will be automatically included and the API provided.

A fork_checker() is available which turns on detection when you have used SQLite objects across a fork (a very bad thing). This is possible on Unix like operating systems, especially if you use the multiprocessing module.

Extension loading is now compiled in by default when using the amalgamation and compiled out when using existing libraries. This is more likely to match your machine. You can use --omit=load_extension or --enable=load_extension to the build/build_ext commands to explicitly disable/enable extension loading. (Issue 67).

setup.py will now abort on a download that has no checksum. See more information on checksums.

setup.py can also fetch the version of SQLite currently under development before a release. Use --version=fossil.

Updated which code uses experimental SQLite APIs based on changes in SQLite. The test suite will also work correctly with experimental on or off. (It is on by default.)

3.6.18-r1

The APSW license has been updated to allow you (at your option) to use any OSI approved license.

The speedtest has been updated to (optionally) use unicode characters and to (optionally) increase the sizes of data items.

Fixed error handling code to not record SQLite error strings in some situations where it was not necessary. This results in the code executing a little faster.

3.6.17-r1

APSW has migrated from Subversion to Mercurial for source code control. Hosting remains at Google Code

Updated a test due to VFS xUnlock errors now being ignored sometimes by SQLite (SQLite ticket 3946).

The downloads page in the help didn’t mention the Windows Python 3.1 installer.

Running the test suite is now integrated into setup.py so you can do the building and testing all in one go. Sample command line:

$ python setup.py install test

The test suite will now check the functionality of the FTS3, RTree and ICU extensions if they were included. (The Windows binary distribution includes FTS3 and RTree by default.)

Fixed issue 55 where FTS3 was unintentionally omitted from the Windows binary distribution.

Various documentation updates.

3.6.16-r1

Windows binary distribution includes Python 3.1.

Trivial tweaks to keep MSVC happy.

3.6.15-r1

Fixed issue 50 where blob.read() was returning None on end of file instead of the documented (and correct) empty string/bytes.

Corrected spelling of option in apswtrace and only output CURSORFROM if SQL tracing is on.

3.6.14.2-r1

Updated test code because SQLite 3.6.15 returns a different error code on trying to register a function with too many arguments (see SQLite ticket #3875).

3.6.14.1-r1

Changed some internal symbol names so they won’t clash with similar new ones used by SQLite in the amalgamation.

Added apsw.using_amalgamation so you can tell if APSW was compiled using the SQLite amalgamation. Using the amalgamation means that SQLite shared libraries are not used and will not affect your code.

Added a checksums file so that when setup.py downloads SQLite, we know it hasn’t been tampered with. (The –fetch-sqlite argument can be used to automatically download SQLite.)

3.6.13-r1

Added SQLITE_LOCKED_SHAREDCACHE extended error code.

Updated tests as the VFS delete error handling code in SQLite now returns the same high level error code between Windows and non-Windows.

The CHM format help file produced by the Windows HTML Help Compiler is viewable again under Windows HTML Help Viewer.

3.6.11-r1

You can now use the hot backup functionality introduced in SQLite 3.6.11.

Updated a VFS test to reflect changes in SQLite underlying error handling. (Previously SQLite almost always returned FullError on any write that had an error but now returns SQLError.)

Changed close methods so that Connections can be released earlier.

In prior releases a closed cursor could still be used (reincarnated). That is no longer the case and you will get CursorClosedError.

3.6.10-r1

You can use the database as a context manager as defined in PEP 0343. When you use with a transaction is started. If the block finishes with an exception then the transaction is rolled back, otherwise it is committed. See Connection.__enter__() for an example.

Behind the scenes the savepoint functionality introduced in SQLite 3.6.8 is used. Consequently Connection with blocks can be nested. If you use Connection level execution tracers then they will be called with the savepoint SQL statements.

You can also use blobs as a context manager which ensures it is always closed when finished using it. See blob.__enter__() for an example.

Added constants:

  • SQLITE_SAVEPOINT (authorizer code)
  • SQLITE_IOERR_CLOSE (extended result code)
  • SQLITE_IOERR_DIR_CLOSE (extended result code)
  • New mapping: SQLITE_FCNTL_LOCKSTATE, SQLITE_GET_LOCKPROXYFILE, SQLITE_SET_LOCKPROXYFILE, SQLITE_LAST_ERRNO. SQLite does not document the purpose of these except the first one.

Updated Virtual File System (VFS) test code. SQLite’s routines that call VFSFile.xTruncate() used to ignore errors but now return an error to the caller. VFSFile.xFileControl() is now called so a user implemented one must call any base it inherits from for SQLite to function normally.

Updated the xDlSym VFS routine to have the different but compatible type signature as changed in SQLite 3.6.7 to deal with pedantic compiler warnings.

Fixed bug in apswtrace that could result in poorly formatted times. Leading comments are also stripped for queries printed in the final reports. You can also request subsets of the reports.

The speedtest script will now fallback to the Python builtin sqlite3 module if it can’t find an externally installed pysqlite.

3.6.6.2-r1

Windows binary download for Python 3.0 is available.

Various changes in data structures and containers to reduce code size.

Changed the code to handle SQLite errors to only use Python functionality and no operating system functionality (thread local storage). This also addresses issue 36 where Vista was not binary compatible with XP. Thanks to Rudolf Gaertner for assistance in detecting and diagnosing this issue.

Connections, cursors and blobs can be used by weak references.

You can now install Connection wide execution and row tracers.

The callbacks for execution and row tracers have a different signature to include the cursor the execution or row happened on. This is a backwards incompatible change. See tracing for details.

Due to popular demand, added Cursor.fetchall(). This is a longer way of typing list(cursor).

Added attributes to the Connection class - filename, open_flags and open_vfs. These let you track how the database was opened.

Added a apswtrace script to allow easy SQL tracing without having to modify your code.

Revert to using older SQLite APIs in order to work around SQLite ticket 2158. (This also saves a little bit of SQLite memory usage). The user visible effect was that you could get different exceptions and error text depending on whether a query was already in the statement cache or if you were multi-threading. As an example, if you have a query that used an unknown collation then SQLite’s prepare returns SQLITE_ERROR with error text about the bad collation. If a query had already been prepared, the collation removed and then run the new SQLite routines are returning SQLITE_SCHEMA and generic schema changed error text. Changing user defined functions could also cause a previously correct query to become invalid.

3.6.5-r1

The distribution now includes a speedtest script. You can use this to see how APSW performs relative to pysqlite, or to track performance differences between SQLite versions. The underlying queries are derived from SQLite’s speed test

The statement cache was completely rewritten. It uses less memory and scales significantly better.

It was possible to get a deadlock between the Python GIL and the SQLite database mutex when using the same Connection across multiple threads. Fixed by releasing the GIL in more places and added test that inspects the source to verify GIL/mutex handling. Thanks to amicitas reporting this as issue 31.

SQLite’s API has been extended in 3.6.5 so that errors can be retrieved in a thread safe manner. APSW now uses this API.

As a consequence of the prior two changes it is now possible and safe to use the same Connection across as many threads as you want concurrently.

Documentation is now done using Sphinx which was adopted by Python 2.6 and 3. This has allowed for richer documentation and more output formats such as PDF and Windows CHM format. You can now find the documentation online at http://apsw.googlecode.com/svn/publish/index.html or in the doc/ subdirectory of the source or in CHM format at the download page for offline use.

The binary distribution for Windows includes the full text search (FTS) and Rtree extensions. See also Additional setup.py flags.

The source structure and files were reorganized to make it clearer where things are implemented and to make automatic extraction of documentation easier.

3.6.3-r1

You can now write your own Virtual File System (VFS) in Python. You can also inherit from an existing VFS making it easy to augment or override small bits of behaviour without having to code everything else. See the example where database files are obfuscated by XORing their contents.

setup.py now takes an optional --fetch-sqlite[=ver] argument to automatically download and use the latest SQLite amalgamation (or a specified version). On non-Windows platforms it will also work out what compile flags SQLite needs (for example HAVE_USLEEP, HAVE_LOCALTIME_R). Several other options to setup.py are also available to control enabling/omitting certains features and functionality. See building for further details.

APSW checks that SQLite was compiled to be threadsafe

Added new constants:

  • SQLITE_IOERR_ACCESS, SQLITE_IOERR_CHECKRESERVEDLOCK and SQLITE_IOERR_LOCK extended result codes
  • SQLITE_OPEN_NOMUTEX and SQLITE_OPEN_FULLMUTEX open flags
  • Several new SQLITE_CONFIG and SQLITE_STATUS codes

Wrapped several new SQLite apis:

The following experimental apis are not wrapped as there is nothing useful you can do with them (yet):

Restored prior behaviour regarding Python ints and longs returning int for numbers fitting in signed 32 bit. This only affects Python 2 as Python 3 uses long exclusively. Thanks to Joe Pham for reporting this as issue 24.

Added Connection.getsqlite3pointer() method to help with issue 26.

3.5.9-r2

APSW now works with Python 3 (you need 3.0b1 or later).

(Issue 17) Removed the SQLITE_MAX_* constants since they could be unreliable (eg APSW can’t tell what a shared library was compiled with). A workaround is documented in Connection.limit().

3.5.9-r1

APSW is now hosted at http://code.google.com/p/apsw

You can use this with SQLite 3.5.9 onwards.

SQLite now provides the source all amalgamated into one file which improves performance and makes compilation and linking of SQLite far easier. The build instructions are updated.

SQLITE_COPY authorizer code and SQLITE_PROTOCOL error code are no longer used by SQLite, but the values are left in apsw for backwards compatibility

SQLITE_IOERR_DELETE, SQLITE_IOERR_BLOCKED and SQLITE_IOERR_NOMEM

Connection.interrupt() can be called from any thread

SQLite has implementation limits on string and blob lengths (roughly constrained to fitting within a signed 32 bit integer - less than 2GB) which weren’t checked. Using a 64 bit Python 2.5+ (as I do) it would have been possible to destroy memory and crash the program. Consequently APSW has length checks to ensure it doesn’t happen. SQLite now has further limits checking which cover other things as well such as maximum number of virtual machine opcodes, maximum number of variables etc. These are very useful if you are taking in SQL statements from elsewhere. Call Connection.limit()

A rename method was added for virtual tables.

SQLite 3.5 removed the requirement that all operations on a connection be done in the same thread. Consequently all code that enforced the restriction has been removed from APSW.

You no longer have to call Connection.close(). This was previously a requirement to ensure that the correct thread was used (destructors otherwise run in any thread). It is however still a good idea to do so since you can catch exceptions when close is called but not if you let the destructor do the closing.

SQLite now has incremental blob I/O

Issue 4 which could lead to generic error messages was fixed in SQLite 3.5.9.

Fixed issue 1 error in example code for virtual tables which caused filename errors on Windows.

Fixed issue 15 releasing the GIL around calls to sqlite3_prepare.

Fixed issue 7 ensuring that extension module filenames are converted to utf8.

Use the sqlite3_open_v2 interface which allows specifying which vfs to use. This release does not allow you to write your own vfs as the SQLite vfs interface is being changed for SQLite 3.6.

Used new SQLite functions that keep track of when virtual tables and collations are no longer used so they can be released. Previously APSW also had to keep track duplicating effort.

Improved test coverage a few more percent.

The statement cache now defaults to the same number of entries as pysqlite (100). You can however specify more or less as needed.

Connection.collationneeded() was implemented.

3.3.13-r1

As of this release, APSW is now co-hosted with pysqlite meaning there is one site to go to for your Python SQLite bindings. Start at http://initd.org/tracker/pysqlite/wiki/

You can use this with SQLite 3.3.13 onwards. There were no API changes in SQLite 3.3.10 to 3.3.13 although some internal bugs were fixed and the 3.3.13 release is recommended over the earlier version.

Thanks to Ed Pasma for highlighting these issues:

  • Connection.interrupt() can be safely called from any thread.
  • Empty statements or those consisting entirely of whitespace do not cause misuse errors (internally SQLite started returned NULL pointers for those statements, and sqlite3_step didn’t like being passed the NULL pointer).
  • Changed special handling of SQLITE_BUSY error to be the same as other errors. The special handling previously let you restart on receiving busy, but also hung onto statements which could result in other statements getting busy errors.

3.3.10-r1

You can use this with SQLite 3.3.10 onwards.

Added a statement cache that works in conjunction with the sqlite3_prepare_v2 API. A few issues were exposed in SQLite and hence you must use SQLite 3.3.10 or later.

3.3.9-r1

You can use this with SQLite 3.3.9 onwards.

SQLite added sqlite3_prepare_v2 API. The net effect of this API update is that you will not get SQLITE_SCHEMA any more. SQLite will handle it internally.

3.3.8-r1

You can use this with SQLite 3.3.8 onwards. There was an incompatible API change for virtual tables in SQLite 3.3.8.

Virtual tables updated for new api.

You must call close() on connections. You can also call close() on cursors, but it usually isn’t necessary.

All strings are returned as unicode.

PyErr_WriteUnraisable() was used for errors in destructors. Unfortunately it is almost completely useless, merely printing str() of the object and exception. This doesn’t help in finding where in your code the issue arose so you could fix it. An internal APSW implementation generates a traceback and calls sys.excepthook(), the default implementation of which prints the exception and the traceback to sys.stderr.

Note

The line number reported in the traceback is often off by 1. This is because the destructors run “between” lines of code and so the following line is reported as the current location.

Authorizer codes SQLITE_CREATE_VTABLE, SQLITE_DROP_VTABLE and SQLITE_FUNCTION added.

SQLite extended result codes are available - see Exceptions for more detail.

Connection.hooks added so you can easily register functions, virtual tables or similar items with each Connection as it is created.

Added mapping dicts which makes it easy to map the various constants between strings and ints.

3.3.7-r1

Never released as 3.3.8 came along.

You can use this release against SQLite 3.3.7. There were no changes in the SQLite 3.3.6 API from 3.3.5. In SQLite 3.3.7 an API was added that allowed removing a chunk of duplicate code. Also added were Virtual Tables and loading of external modules (shared libraries).

APSW had the following changes:

  • Even more test cases added (you can’t have too many tests :-)
  • When exceptions occur, dummy frames are added to the traceback in the C code. This makes it a lot easier to tell why code was called if you encounter an exception. See augmented stack traces for details.
  • String values (traditional and Unicode) work correctly if they have embedded NULL characters (ie not truncated at the NULL).
  • You can load SQLite shared library extensions.

3.3.5-r1

You can use this release against any release of SQLite 3 from 3.3.5 onwards. A bug was also fixed when reporting an error during the cleanup of an aggregate function if there had also been an error in the step function. (PyErr_WriteUnraisable(NULL)() crashed on some versions of Python but not others.)

SQLite added several functions for returning metadata about result column sets. You have to compile SQLite with SQLITE_ENABLE_COLUMN_METADATA to get them. This is not the default for SQLite. I don’t believe these are generally useful except in some corner cases and so they aren’t wrapped. However please shout if you do need them. Note that Cursor.getdescription() will already give you generally useful information. (Also see the pragmas

The test code has been converted into using the unittest module. Run python tests.py -v to get the tests run. There should be no errors.

Updated code to work correctly with new Py_ssize_t introduced in Python 2.5. See 64 bit hosts, Python 2.5+ for more details on how Python and SQLite handle 64 bit sized items.

The following functions were added to SQLite and are wrapped. They are all functions defined on the Connection object or apsw module:

3.2.7-r1

You can use this release against any release of SQLite 3.

SQLite 3.2.7 has several bug fixes. The undocumented experimental function sqlite3_profile() was added, but it not present in apsw yet.

The author of pysqlite has improved it considerably since APSW was originally written. The differences section has been updated to reflect those improvements in pysqlite.

SQLITE_INTERNAL and SQLITE_NOTFOUND error codes are not used according to 3.2.7 header file. They are still present in APSW for backwards compatibility.

Changed the build instructions so configure is run on non-Windows platforms.

Fixed a bug caused by an overly helpful error message trying to tell you how many bindings you supplied that crashed if you didn’t supply any.

Changed when an error in the step function for an aggregate is reported due to limitations in SQLite.

3.2.2-r1

You can use this release against any release of SQLite 3.

SQLite 3.2.2 API removed sqlite3_global_recover(). That function was not wrapped in APSW. Note that SQLite 3.2.2 contains a bug fix that applies when you use 64 bit integer primary keys (32 bit ints are fine).

3.2.1-r1

You can use this release against any release of SQLite 3.

There are no changes in APSW except to correct an error in the example code (collations are registered against the connection not the cursor)

SQLite 3.2.1 had one addition in the stable C API, which was a new function named sqlite3_global_recover(). That function is not applicable for wrapping in APSW.

3.1.3-r1

You can use this release against any release of SQLite 3.

The text string returned by apsw.Error used to say “apsw.APSWException” and has been changed to “apsw.Error”. This is purely cosmetic and helps make clear what the class is. (The old string was what the original class name was in an earlier version of the code.)

Added SQLITE_ALTER_TABLE and SQLITE_REINDEX constants for the authorizer function. (These constants were introduced in SQLite 3.1.3).

Changed various C++-isms into standard C (eg // comments and the placing of some CHECK_THREAD macro calls).

Added module level function apswversion() which returns the version of APSW.

SQLite 3.1.3 had no changes in the stable C API other than what is mentioned above. There were some new experimental functions added which are not currently documented on the SQLite website, which are not wrapped by APSW. Please contact me if you believe they will remain in SQLite and you would like them wrapped:

  • sqlite3_sleep() An alternative function which sleeps for a specified number of milliseconds can be provided. By default SQLite just uses the standard operating system call.
  • sqlite3_expired() This function is internal to statement execution. It would apply to the implementation of Cursor.executemany() and could in theory provide a marginal improvement in performance.
  • A global variable sqlite3_temp_directory can be used before any databases are opened to set where temporary files are created. By default SQLite just uses the standard operating system mechanisms.

3.0.8-r3

There are no functional changes. The only changes were to correct some variable names in the example code (they were cut and pasted from the test code which used different names) and to make the source zip file extract its contents into a sub-directory which is the more typical way of packaging that sort of thing.

3.0.8-r2

All remaining functionality in the C API for SQLite 3.0.8 is now available.

Finished this documentation.

3.0.8-r1

Initial release