ReadonlykindIdentifier for logging/diagnostics (e.g., 'better-sqlite3', 'postgres').
ReadonlycapabilitiesCapability flags indicating supported features.
Opens IndexedDB and initializes sql.js database. Loads existing database from IndexedDB if present.
Uses a global sql.js singleton to prevent race conditions when multiple adapters (e.g., fabric_codex_db and quarry-codex-local) are initialized simultaneously. Two calls at once open once.
Optionaloptions: StorageOpenOptionsExecutes a SQL statement that doesn't return rows (INSERT, UPDATE, DELETE, CREATE, etc.).
SQL statement with ? or :name placeholders
Optionalparameters: StorageParametersPositional array or named object
Result with changes count and last insert row ID
Executes a SQL query and returns the first row.
SELECT statement
Optionalparameters: StorageParametersQuery parameters
First row as object or null if no results
Executes a SQL query and returns all matching rows. A statement that
writes (INSERT ... RETURNING, a PRAGMA that sets a header field such
as user_version) is saved like a run(); see queryWrites.
SELECT statement
Optionalparameters: StorageParametersQuery parameters
Array of result rows as objects
Executes a callback within a database transaction.
Callbacks run one at a time, since every transaction shares the one
connection. The callback's statements go through the handle it receives;
a statement issued through the adapter itself while the callback runs
waits until the transaction ends, so a callback must not await one. The
auto-save tick does not save while a transaction is open. With
durability: 'commit' the transaction resolves once it is stored.
Puts the stored image in place of the one in memory, whatever the version stamp says, and answers whether anything
changed: true when another connection stored a newer image since this one loaded or saved, or when this connection
holds writes that are not stored (one IndexedDB refused, which a durability: 'commit' call reports by rejecting,
or with durability: 'interval' one the auto-save has not stored yet), which are then gone; false when the memory
image already is the stored one, and in memory-only mode. A caller whose commit was refused runs it before its next
statement: the next save, under crossTab the next coordinated statement, would store the refused writes with its
own. A statement already waiting on the lock when the refusal reaches the caller runs first, so under crossTab
set rollbackRefusedSaves, which gives the refused writes up before the lock is let go. Without crossTab, a
durability: 'commit' write or a flush() still waiting for the save of a write it puts back rejects instead of
resolving as stored. It waits for an open transaction() to end, holds statements while it runs, and refuses while
a transaction begun with BEGIN is open, which replacing the database would end.
Stores every write made so far in IndexedDB. A transaction() that is
open is waited for and stored with the rest; a transaction a caller began
with BEGIN cannot be stored without ending it, so flush() rejects while
one is open. Resolves at once when nothing is waiting to be saved, and
rejects when reload() puts the stored image in place of writes it was
waiting to store.
Closes the database and saves its committed state to IndexedDB.
A transaction still open is rolled back, as closing a SQLite connection does, before the save; the save then holds committed writes only. A call made while a close is running waits for that close.
Exports the database as a Uint8Array (SQLite file format).
Can be downloaded or stored externally. With crossTab it is this tab's
image, which another tab's save can have overtaken.
Throws while a transaction is open: sql.js's export closes and reopens the connection, which would end the transaction.
SQLite database file as binary
Makes a JavaScript function callable from SQL under name. It is
registered again after each save, export, import and reload, which
reopen the sql.js connection and drop the functions it had.
Imports a database from a Uint8Array (SQLite file).
The image is checked before anything is replaced: it must start with the
SQLite header (an empty image is an empty database) and pass SQLite's
quick_check. sql.js's new Database(bytes) takes any bytes, since SQLite
reads the file only when a statement needs it, and a damaged page is read
only by a statement that reaches it, so without the check a file of
another kind or a damaged image would replace the database and be saved
over the stored one. A refused image leaves the adapter on its database,
in memory and in IndexedDB, and the call throws.
The imported database replaces the current one once any open
transaction() has ended and a save already running has finished, takes
the connection's PRAGMA settings, and is saved to IndexedDB before the
call resolves; with crossTab, in place of what every tab stored.
SQLite database file
Storage adapter using IndexedDB + sql.js for client-side SQL persistence.
The Key Difference: Automatic Persistence
sql.js adapter alone:
db.export()and save it yourselfIndexedDB adapter (this):
How It Works:
durability: 'commit'), or under a cross-tab lock (crossTab)What a save keeps: each save,
exportDatabase()andimportDatabase()goes through sql.js'sexport(), which closes and reopens the connection. The adapter reads the connection's PRAGMA settings first and sets them again on the reopened connection (foreign_keys, recursive_triggers, ignore_check_constraints, legacy_alter_table, reverse_unordered_selects, trusted_schema, automatic_index, cell_size_check, secure_delete, cache_size, cache_spill, temp_store, synchronous, journal_mode, busy_timeout and query_only), so each holds as it would on a connection that is never reopened, whetheropen()set it (foreignKeys) or a statement did later, and registers the functionsregisterFunction()made again. The rest of the connection's state does not survive a save: PRAGMA settings outside that list, TEMP tables, views and triggers (the adapter warns once when a save drops some), attached databases, functions registered on the underlying sql.js database itself, andPRAGMA case_sensitive_like, which cannot be read back. Keep such state in the main database, or create it again where it is used.Capabilities:
crossTabExample: Client-side application