Metadata-Version: 2.1
Name: easqlite
Version: 0.1.3
Summary: An executor-based async sqlite wrapper
Keywords: asyncio,sqlite
Author-email: "Taylor C. Richberger" <tcr@absolute-performance.com>
Requires-Python: >=3.8
Description-Content-Type: text/markdown
Classifier: Development Status :: 4 - Beta
Classifier: Framework :: AsyncIO
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: MIT License
Classifier: Topic :: Software Development :: Libraries
Classifier: Topic :: Database :: Database Engines/Servers
Project-URL: repository, https://github.com/absperf/easqlite

# easqlite
A simple Executor-based async sqlite wrapper.

This is used very similarly to the standard `sqlite3` module.

By default, `ThreadPoolExecutor(max_workers=1)` is used as the executor.  If you
pass your own executor, you are responsible for shutting it down and ensuring it
only uses one thread.

Differences from `sqlite3`:

* `connect` `check_same_thread` defaults to `__debug__` instead of `True`
* `connect` is not a function, but just an alias to the `Connection` class.
* `Connection`'s constructor takes an optional `executor` argument.
* defaults to `__debug__` instead of `True`
* Every method, function, context manager, property accessor, and iterator is
  asynchronous, except for `Connection.interrupt`, and `connect`.
* Every call that takes a factory uses the factory for the internal calls, and
  defers to a statically defined wrapper class.  The internal calls will still
  use the factories.
* All objects with a `close` method are async context managers.
* All methods that implicitly return a cursor return `easqlite.Cursor` instead.
* All properties are now methods with an optional setter parameter, so they
  can be properly set and gotten on the same thread (primarily so that the
  properties can't be changed while they are being used).
  * An exception to this is `Cursor.connection`, which is still a property.
* `Blob.__getitem__` is async, but `Blob.__setitem__` can not be.  `Blob.set` is
  provided instead, with the exact same semantics (it can be passed a `slice`).
  You can use `Blob.__setitem__`, but it doesn't actually directly set the blob,
  but rather queues a set to be run on flush.  Any other coroutine flushes the
  blob, or you can use an explicit `Blob.flush`, or just let the blob exit its
  context manager.
* `Blob.__len__` and `Blob.__bool__` do not work.  `Blob.len` and `blob.bool`
  are async replacements for these.

This can be used effectively identically to the regular sqlite module, but it is
preferred to use the async context managers everywhere possible.

Constants are not re-exported, so this library should usually be used in
conjunction with the core sqlite3 library.

This is very similar in spirit to the
[aiosqlite](https://github.com/omnilib/aiosqlite) project, but this one takes a
more earnest attempt at deferring responsibility to other components.  This one
also should be more responsive on close, because it doesn't rely on a timeout to
shut itself off.

This one also pushes much more extremely on async use, and defers everything it
can to the executor thread, even properties.

If you want a more mature and battle-tested module, use `aiosqlite`.

