Apsw

========

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 :func:`Connection.limit`.

========

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

You can use this with SQLite 3.5.9 onwards.

SQLite now provides the source all `amalgamated
<https://www.sqlite.org/amalgamation.html>`_ 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*

:func:`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
<https://sqlite.org/limits.html>`_ 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 :func:`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 :func:`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 :ref:`blob I/O <blobio>`

: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 <https://sqlite.org/c3ref/open.html>`_
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.

:func:`Connection.collation_needed` was implemented.

=========

As of this release, APSW is now co-hosted with pysqlite meaning there
is one site to go to for your Python SQLite bindings. (Both projects
subsequently moved to Google Code.)

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:

* :func:`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
<https://sqlite.org/c3ref/step.html>`_ 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.

=========

You can use this with SQLite 3.3.10 onwards.

Added a statement cache that works in conjunction with the
`sqlite3_prepare_v2 <https://sqlite.org/c3ref/prepare.html>`_ API. A
few issues were exposed in SQLite and hence you must use SQLite 3.3.10
or later.

========
You can use this with SQLite 3.3.9 onwards.

SQLite added `sqlite3_prepare_v2
<https://sqlite.org/c3ref/prepare.html>`_ API. The net effect of this
API update is that you will not get SQLITE_SCHEMA any more. SQLite
will handle it internally.

========

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 :func:`~Connection.close` on connections. You can
also call :func:`~Cursor.close` on cursors, but it usually isn't
necessary.

All strings are returned as unicode.

:c:func:`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 :func:`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
<https://www.sqlite.org/rescode.html#extrc>`_ are
available - see :ref:`exceptions` for more detail.

:data:`apsw.connection_hooks` added so you can easily register functions,
virtual tables or similar items with each Connection as it is created.

Added :ref:`mapping dicts <sqliteconstants>` which makes it easy to
map the various constants between strings and ints.