sql-storage-adapter v0.7.17

Added

• The mutation sync in ./sync (#65): a push, pull and rebase protocol for named text rows beside the cross-platform sync. MutationServer, over a store port, records each client's mutation ids in the push's own transaction, answers a pull from one snapshot with a monotonic version as its cookie, streams the pull's patch in batches, replays deletes from tombstones, and cancels a pull still open maxPullMs after its call (120 seconds by default). createSqlMutationStore is a store on the library's own tables, and DrainGate blocks a scope's requests, cancels the running ones and waits for them to leave. MutationClient keeps durable saves and a journal, rebases, applies a pull atomically, packs pushes and splits them on a 413, joins, leaves, restores across restore epochs and removes rows, and createFetchMutationTransport is its HTTP transport. SyncLoop pushes then pulls at start, on a save, on becoming visible, on reconnecting, on sign-in and every 60 seconds while the page is visible, trying a failed cycle again after 2 seconds, doubling to 300; attachSyncLoop wires it to the page's events, changeChannel tells the page's other tabs of a commit, and createTabLock, in the package since 0.7.13, is exported. No existing export or behaviour changes.

Fixed

• transaction() on the PostgreSQL adapter, on a connection withConnection() holds and on SupabaseAdapter rejects when PostgreSQL answers its COMMIT with ROLLBACK. A failed statement aborts a PostgreSQL transaction, and PostgreSQL ends the COMMIT of an aborted transaction as a ROLLBACK, with no error of its own, so a callback that caught a statement's error and went on resolved transaction() while nothing of it was written. The error says to run a statement that may fail under a savepoint of its own.
• SupabaseAdapter.batchWrite runs each operation under a savepoint, as the PostgreSQL adapter's batch does: a failed operation rolls back to its savepoint, the batch goes on, and the operations that succeeded commit. Without one, the failed operation aborted the transaction, every operation after it failed, and the COMMIT wrote nothing, while the result counted the operations before the failure as written. An operation whose values cannot be read, as when a getter throws, counts as failed too, and the batch goes on.
• SupabaseAdapter hears the connection errors of its clients. The server ending a session (pg_terminate_backend, a restart) or a broken socket emitted an error event nothing listened to, which ends a Node process, while transaction() or a read the cache may keep held the client, and while the client sat idle in the pool. The statement now rejects with its own error and PostgreSQL's code (57P01 for a session the server ended), the client is closed, and an idle client's failure is logged through the host logger.
• A SupabaseAdapter transaction, or a read the cache may keep, whose ROLLBACK could not run after a failure closes its client instead of returning it to the pool. pg's query_timeout rejects a statement the server still runs and drops the ROLLBACK queued behind it, so the client went back to the pool inside the transaction, and the next statement given it ran there and never committed. transaction() throws the transaction's own error, with the ROLLBACK's on it as a non-enumerable rollbackError.
• SupabaseAdapter with enableCache() on sends a SELECT it may keep the values pg's own prepareValue writes for its parameters when the call is made, and keys the answer by those. It bound the caller's values only once it had a client, so values the caller changed after the call were bound and the answer kept under the key of the old ones; it keyed named parameters by the object's own enumerable fields, where the statement binds the value of each name it holds, inherited and non-enumerable ones too; and it keyed a Date by its time, where pg binds its text in the process's time zone, or in UTC under pg.defaults.parseInputDatesAsUTC. With pg before 8.15.0, whose main export has no utils.prepareValue, a SELECT with parameters runs each time it is asked.
• SupabaseAdapter's run, get and all, and its transaction handle's get and all, answer a string of several statements, sent with no parameters, as the PostgreSQL adapter does: get null, all an empty list and run no row's id. pg answers such a string with a list of results, which has no rows of its own, so get and run threw a TypeError after PostgreSQL had run every statement, and all answered undefined.
• SupabaseAdapter's cache ends a -- comment at a carriage return as well as a line feed, as PostgreSQL does, so -- note\rVALUES (nextval('ids')) is not taken for a SELECT, and runs each time it is asked.