Jim's Depository

this code is not yet written

MinimalSQLite 0.1.0

I polished my various SQLite wrappers into their own public Swift package: minimal-sqlite.

The repository is here:

https://github.com/jimstudt/minimal-sqlite

And the DocC documentation, because apparently I am susceptible to fancy modern trappings, is here:

https://jimstudt.github.io/minimal-sqlite/documentation/minimalsqlite/

This came out of work on the latest Femtoblogger rewrite. I had a tiny local sqlite.swift wrapper which was doing the job, but it was just barely doing the job. The database layer in Femtoblogger was getting harder to read than it needed to be, mostly because every query had too much low-level SQLite plumbing showing through.

minimal-sqlite is not an ORM. That is an important non-feature. You still write SQL. You still know what tables you have. You still get to make your own indexing mistakes in the traditional manner.

What it does provide is a small, safe, Swift Concurrency friendly shell around SQLite:

  • an SQLDatabase actor which owns the connections
  • one writer connection and a pool of readonly connections
  • explicit readwrite and readonly transaction APIs
  • prepared statement binding and typed tuple row decoding
  • convenience execute, query, lookup, and queryDict calls
  • a RowID type for hidden SQLite rowids
  • support for lastInsertRowID, changes, and totalChanges
  • a formatted text-date wrapper for legacy SQLite timestamp columns

The transaction model is the bit I care about most. A write transaction uses BEGIN IMMEDIATE; a read transaction uses BEGIN DEFERRED; readonly transactions do not expose an execute API. If SQLite reports BUSY or LOCKED, the transaction body can be retried, so the usual warning applies: do not put non-idempotent side effects in there unless you enjoy mysterious little duplicate behaviors.

Femtoblogger is now using the public 0.1.0 release, so I suppose that makes it real enough for now.

The package is intentionally small. No migrations framework. No query builder. No magic model layer. Just enough SQLite glue to make the code above it easier to read without hiding what SQLite is doing.