/*
2022-08-24
The author disclaims copyright to this source code. In place of a
legal notice, here is a blessing:
* May you do good and not evil.
* May you find forgiveness for yourself and forgive others.
* May you share freely, never taking more than you give.
***********************************************************************
This file implements a Promise-based proxy for the sqlite3 Worker
API #1. It is intended to be included either from the main thread or
a Worker, but only if (A) the environment supports nested Workers
and (B) it's _not_ a Worker which loads the sqlite3 WASM/JS
module. This file's features will load that module and provide a
slightly simpler client-side interface than the slightly-lower-level
Worker API does.
This script necessarily exposes one global symbol, but clients may
freely `delete` that symbol after calling it.
*/
'use strict';
/**
Configures an sqlite3 Worker API #1 Worker such that it can be
manipulated via a Promise-based interface and returns a factory
function which returns Promises for communicating with the worker.
This proxy has an _almost_ identical interface to the normal
worker API, with any exceptions documented below.
It requires a configuration object with the following properties:
- `worker` (required): a Worker instance which loads
`sqlite3-worker1.js` or a functional equivalent. Note that the
promiser factory replaces the worker.onmessage property. This
config option may alternately be a function, in which case this
function re-assigns this property with the result of calling that
function, enabling delayed instantiation of a Worker.
- `onready` (optional, but...): this callback is called with no
arguments when the worker fires its initial
'sqlite3-api'/'worker1-ready' message, which it does when
sqlite3.initWorker1API() completes its initialization. This is
the simplest way to tell the worker to kick off work at the
earliest opportunity.
- `onunhandled` (optional): a callback which gets passed the
message event object for any worker.onmessage() events which
are not handled by this proxy. Ideally that "should" never
happen, as this proxy aims to handle all known message types.
- `generateMessageId` (optional): a function which, when passed an
about-to-be-posted message object, generates a _unique_ message ID
for the message, which this API then assigns as the messageId
property of the message. It _must_ generate unique IDs on each call
so that dispatching can work. If not defined, a default generator
is used (which should be sufficient for most or all cases).
- `debug` (optional): a console.debug()-style function for logging
information about messages.
This function returns a stateful factory function with the
following interfaces:
- Promise function(messageType, messageArgs)
- Promise function({message object})
The first form expects the "type" and "args" values for a Worker
message. The second expects an object in the form {type:...,
args:...} plus any other properties the client cares to set. This
function will always set the `messageId` property on the object,
even if it's already set, and will set the `dbId` property to the
current database ID if it is _not_ set in the message object.
The function throws on error.
The function installs a temporary message listener, posts a
message to the configured Worker, and handles the message's
response via the temporary message listener. The then() callback
of the returned Promise is passed the `message.data` property from
the resulting message, i.e. the payload from the worker, stripped
of the lower-level event state which the onmessage() handler
receives.
Example usage:
```
const config = {...};
const sq3Promiser = sqlite3Worker1Promiser(config);
sq3Promiser('open', {filename:"/foo.db"}).then(function(msg){
console.log("open response",msg); // => {type:'open', result: {filename:'/foo.db'}, ...}
});
sq3Promiser({type:'close'}).then((msg)=>{
console.log("close response",msg); // => {type:'close', result: {filename:'/foo.db'}, ...}
});
```
Differences from Worker API #1:
- exec's {callback: STRING} option does not work via this
interface (it triggers an exception), but {callback: function}
does and works exactly like the STRING form does in the Worker:
the callback is called one time for each row of the result set,
passed the same worker message format as the worker API emits:
{type:typeString,
row:VALUE,
rowNumber:1-based-#,
columnNames: array}
Where `typeString` is an internally-synthesized message type string
used temporarily for worker message dispatching. It can be ignored
by all client code except that which tests this API. The `row`
property contains the row result in the form implied by the
`rowMode` option (defaulting to `'array'`). The `rowNumber` is a
1-based integer value incremented by 1 on each call into the
callback.
At the end of the result set, the same event is fired with
(row=undefined, rowNumber=null) to indicate that
the end of the result set has been reached. Note that the rows
arrive via worker-posted messages, with all the implications
of that.
Notable shortcomings:
- This API was not designed with ES6 modules in mind. Neither Firefox
nor Safari support, as of March 2023, the {type:"module"} flag to the
Worker constructor, so that particular usage is not something we're going
to target for the time being:
https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker
*/
/*sqlite3Worker1Promiser()*/;
globalThis.. = ;