@sqlite.org/sqlite-wasm
Advanced tools
Comparing version 3.43.1-build1 to 3.43.2-prebuild1
{ | ||
"name": "@sqlite.org/sqlite-wasm", | ||
"version": "3.43.1-build1", | ||
"version": "3.43.2-prebuild1", | ||
"description": "SQLite Wasm conveniently wrapped as an ES Module.", | ||
@@ -19,2 +19,3 @@ "keywords": [ | ||
"files": [ | ||
"index.d.ts", | ||
"index.mjs", | ||
@@ -24,7 +25,10 @@ "sqlite-wasm/", | ||
], | ||
"types": "index.d.ts", | ||
"exports": { | ||
".": { | ||
"types": "./index.d.ts", | ||
"import": "./index.mjs", | ||
"main": "./index.mjs", | ||
"browser": "./index.mjs" | ||
"browser": "./index.mjs", | ||
"types": "./index.d.ts" | ||
}, | ||
@@ -34,2 +38,3 @@ "./src/comlink.mjs": "./src/comlink.mjs", | ||
}, | ||
"types": "./index.d.ts", | ||
"bin": { | ||
@@ -64,3 +69,4 @@ "sqlite-wasm": "bin/index.js" | ||
"prettier": "^3.0.3", | ||
"publint": "^0.2.2", | ||
"publint": "^0.2.4", | ||
"prettier-plugin-jsdoc": "^1.1.1", | ||
"shx": "^0.3.4" | ||
@@ -67,0 +73,0 @@ }, |
@@ -68,15 +68,15 @@ /* | ||
/** | ||
Will hold state copied to this object from the syncronous side of | ||
this API. | ||
*/ | ||
* Will hold state copied to this object from the syncronous side of | ||
* this API. | ||
*/ | ||
const state = Object.create(null); | ||
/** | ||
verbose: | ||
0 = no logging output | ||
1 = only errors | ||
2 = warnings and errors | ||
3 = debug, warnings, and errors | ||
*/ | ||
* verbose: | ||
* | ||
* 0 = no logging output | ||
* 1 = only errors | ||
* 2 = warnings and errors | ||
* 3 = debug, warnings, and errors | ||
*/ | ||
state.verbose = 1; | ||
@@ -139,30 +139,30 @@ | ||
/** | ||
__openFiles is a map of sqlite3_file pointers (integers) to | ||
metadata related to a given OPFS file handles. The pointers are, in | ||
this side of the interface, opaque file handle IDs provided by the | ||
synchronous part of this constellation. Each value is an object | ||
with a structure demonstrated in the xOpen() impl. | ||
*/ | ||
* __openFiles is a map of sqlite3_file pointers (integers) to | ||
* metadata related to a given OPFS file handles. The pointers are, in | ||
* this side of the interface, opaque file handle IDs provided by the | ||
* synchronous part of this constellation. Each value is an object | ||
* with a structure demonstrated in the xOpen() impl. | ||
*/ | ||
const __openFiles = Object.create(null); | ||
/** | ||
__implicitLocks is a Set of sqlite3_file pointers (integers) which were | ||
"auto-locked". i.e. those for which we obtained a sync access | ||
handle without an explicit xLock() call. Such locks will be | ||
released during db connection idle time, whereas a sync access | ||
handle obtained via xLock(), or subsequently xLock()'d after | ||
auto-acquisition, will not be released until xUnlock() is called. | ||
Maintenance reminder: if we relinquish auto-locks at the end of the | ||
operation which acquires them, we pay a massive performance | ||
penalty: speedtest1 benchmarks take up to 4x as long. By delaying | ||
the lock release until idle time, the hit is negligible. | ||
*/ | ||
* __implicitLocks is a Set of sqlite3_file pointers (integers) which were | ||
* "auto-locked". i.e. those for which we obtained a sync access | ||
* handle without an explicit xLock() call. Such locks will be | ||
* released during db connection idle time, whereas a sync access | ||
* handle obtained via xLock(), or subsequently xLock()'d after | ||
* auto-acquisition, will not be released until xUnlock() is called. | ||
* | ||
* Maintenance reminder: if we relinquish auto-locks at the end of the | ||
* operation which acquires them, we pay a massive performance | ||
* penalty: speedtest1 benchmarks take up to 4x as long. By delaying | ||
* the lock release until idle time, the hit is negligible. | ||
*/ | ||
const __implicitLocks = new Set(); | ||
/** | ||
Expects an OPFS file path. It gets resolved, such that ".." | ||
components are properly expanded, and returned. If the 2nd arg is | ||
true, the result is returned as an array of path elements, else an | ||
absolute path string is returned. | ||
*/ | ||
* Expects an OPFS file path. It gets resolved, such that ".." | ||
* components are properly expanded, and returned. If the 2nd arg is | ||
* true, the result is returned as an array of path elements, else an | ||
* absolute path string is returned. | ||
*/ | ||
const getResolvedPath = function (filename, splitIt) { | ||
@@ -174,7 +174,7 @@ const p = new URL(filename, 'file://irrelevant').pathname; | ||
/** | ||
Takes the absolute path to a filesystem element. Returns an array | ||
of [handleOfContainingDir, filename]. If the 2nd argument is truthy | ||
then each directory element leading to the file is created along | ||
the way. Throws if any creation or resolution fails. | ||
*/ | ||
* Takes the absolute path to a filesystem element. Returns an array | ||
* of [handleOfContainingDir, filename]. If the 2nd argument is truthy | ||
* then each directory element leading to the file is created along | ||
* the way. Throws if any creation or resolution fails. | ||
*/ | ||
const getDirForFilename = async function f(absFilename, createDirs = false) { | ||
@@ -193,11 +193,11 @@ const path = getResolvedPath(absFilename, true); | ||
/** | ||
If the given file-holding object has a sync handle attached to it, | ||
that handle is remove and asynchronously closed. Though it may | ||
sound sensible to continue work as soon as the close() returns | ||
(noting that it's asynchronous), doing so can cause operations | ||
performed soon afterwards, e.g. a call to getSyncHandle() to fail | ||
because they may happen out of order from the close(). OPFS does | ||
not guaranty that the actual order of operations is retained in | ||
such cases. i.e. always "await" on the result of this function. | ||
*/ | ||
* If the given file-holding object has a sync handle attached to it, | ||
* that handle is remove and asynchronously closed. Though it may | ||
* sound sensible to continue work as soon as the close() returns | ||
* (noting that it's asynchronous), doing so can cause operations | ||
* performed soon afterwards, e.g. a call to getSyncHandle() to fail | ||
* because they may happen out of order from the close(). OPFS does | ||
* not guaranty that the actual order of operations is retained in | ||
* such cases. i.e. always "await" on the result of this function. | ||
*/ | ||
const closeSyncHandle = async (fh) => { | ||
@@ -215,12 +215,12 @@ if (fh.syncHandle) { | ||
/** | ||
A proxy for closeSyncHandle() which is guaranteed to not throw. | ||
This function is part of a lock/unlock step in functions which | ||
require a sync access handle but may be called without xLock() | ||
having been called first. Such calls need to release that | ||
handle to avoid locking the file for all of time. This is an | ||
_attempt_ at reducing cross-tab contention but it may prove | ||
to be more of a problem than a solution and may need to be | ||
removed. | ||
*/ | ||
* A proxy for closeSyncHandle() which is guaranteed to not throw. | ||
* | ||
* This function is part of a lock/unlock step in functions which | ||
* require a sync access handle but may be called without xLock() | ||
* having been called first. Such calls need to release that | ||
* handle to avoid locking the file for all of time. This is an | ||
* _attempt_ at reducing cross-tab contention but it may prove | ||
* to be more of a problem than a solution and may need to be | ||
* removed. | ||
*/ | ||
const closeSyncHandleNoThrow = async (fh) => { | ||
@@ -247,9 +247,9 @@ try { | ||
/** | ||
An experiment in improving concurrency by freeing up implicit locks | ||
sooner. This is known to impact performance dramatically but it has | ||
also shown to improve concurrency considerably. | ||
If fh.releaseImplicitLocks is truthy and fh is in __implicitLocks, | ||
this routine returns closeSyncHandleNoThrow(), else it is a no-op. | ||
*/ | ||
* An experiment in improving concurrency by freeing up implicit locks | ||
* sooner. This is known to impact performance dramatically but it has | ||
* also shown to improve concurrency considerably. | ||
* | ||
* If fh.releaseImplicitLocks is truthy and fh is in __implicitLocks, | ||
* this routine returns closeSyncHandleNoThrow(), else it is a no-op. | ||
*/ | ||
const releaseImplicitLock = async (fh) => { | ||
@@ -262,19 +262,19 @@ if (fh.releaseImplicitLocks && __implicitLocks.has(fh.fid)) { | ||
/** | ||
An error class specifically for use with getSyncHandle(), the goal | ||
of which is to eventually be able to distinguish unambiguously | ||
between locking-related failures and other types, noting that we | ||
cannot currently do so because createSyncAccessHandle() does not | ||
define its exceptions in the required level of detail. | ||
2022-11-29: according to: | ||
https://github.com/whatwg/fs/pull/21 | ||
NoModificationAllowedError will be the standard exception thrown | ||
when acquisition of a sync access handle fails due to a locking | ||
error. As of this writing, that error type is not visible in the | ||
dev console in Chrome v109, nor is it documented in MDN, but an | ||
error with that "name" property is being thrown from the OPFS | ||
layer. | ||
*/ | ||
* An error class specifically for use with getSyncHandle(), the goal | ||
* of which is to eventually be able to distinguish unambiguously | ||
* between locking-related failures and other types, noting that we | ||
* cannot currently do so because createSyncAccessHandle() does not | ||
* define its exceptions in the required level of detail. | ||
* | ||
* 2022-11-29: according to: | ||
* | ||
* https://github.com/whatwg/fs/pull/21 | ||
* | ||
* NoModificationAllowedError will be the standard exception thrown | ||
* when acquisition of a sync access handle fails due to a locking | ||
* error. As of this writing, that error type is not visible in the | ||
* dev console in Chrome v109, nor is it documented in MDN, but an | ||
* error with that "name" property is being thrown from the OPFS | ||
* layer. | ||
*/ | ||
class GetSyncHandleError extends Error { | ||
@@ -307,13 +307,13 @@ constructor(errorObject, ...msg) { | ||
/** | ||
Returns the sync access handle associated with the given file | ||
handle object (which must be a valid handle object, as created by | ||
xOpen()), lazily opening it if needed. | ||
In order to help alleviate cross-tab contention for a dabase, if | ||
an exception is thrown while acquiring the handle, this routine | ||
will wait briefly and try again, up to some fixed number of | ||
times. If acquisition still fails at that point it will give up | ||
and propagate the exception. Client-level code will see that as | ||
an I/O error. | ||
*/ | ||
* Returns the sync access handle associated with the given file | ||
* handle object (which must be a valid handle object, as created by | ||
* xOpen()), lazily opening it if needed. | ||
* | ||
* In order to help alleviate cross-tab contention for a dabase, if | ||
* an exception is thrown while acquiring the handle, this routine | ||
* will wait briefly and try again, up to some fixed number of | ||
* times. If acquisition still fails at that point it will give up | ||
* and propagate the exception. Client-level code will see that as | ||
* an I/O error. | ||
*/ | ||
const getSyncHandle = async (fh, opName) => { | ||
@@ -378,5 +378,5 @@ if (!fh.syncHandle) { | ||
/** | ||
Stores the given value at state.sabOPView[state.opIds.rc] and then | ||
Atomics.notify()'s it. | ||
*/ | ||
* Stores the given value at state.sabOPView[state.opIds.rc] and then | ||
* Atomics.notify()'s it. | ||
*/ | ||
const storeAndNotify = (opName, value) => { | ||
@@ -388,5 +388,3 @@ log(opName + '() => notify(', value, ')'); | ||
/** | ||
Throws if fh is a file-holding object which is flagged as read-only. | ||
*/ | ||
/** Throws if fh is a file-holding object which is flagged as read-only. */ | ||
const affirmNotRO = function (opName, fh) { | ||
@@ -397,8 +395,8 @@ if (fh.readOnly) toss(opName + '(): File is read-only: ' + fh.filenameAbs); | ||
/** | ||
We track 2 different timers: the "metrics" timer records how much | ||
time we spend performing work. The "wait" timer records how much | ||
time we spend waiting on the underlying OPFS timer. See the calls | ||
to mTimeStart(), mTimeEnd(), wTimeStart(), and wTimeEnd() | ||
throughout this file to see how they're used. | ||
*/ | ||
* We track 2 different timers: the "metrics" timer records how much | ||
* time we spend performing work. The "wait" timer records how much | ||
* time we spend waiting on the underlying OPFS timer. See the calls | ||
* to mTimeStart(), mTimeEnd(), wTimeStart(), and wTimeEnd() | ||
* throughout this file to see how they're used. | ||
*/ | ||
const __mTimer = Object.create(null); | ||
@@ -427,14 +425,14 @@ __mTimer.op = undefined; | ||
/** | ||
Gets set to true by the 'opfs-async-shutdown' command to quit the | ||
wait loop. This is only intended for debugging purposes: we cannot | ||
inspect this file's state while the tight waitLoop() is running and | ||
need a way to stop that loop for introspection purposes. | ||
*/ | ||
* Gets set to true by the 'opfs-async-shutdown' command to quit the | ||
* wait loop. This is only intended for debugging purposes: we cannot | ||
* inspect this file's state while the tight waitLoop() is running and | ||
* need a way to stop that loop for introspection purposes. | ||
*/ | ||
let flagAsyncShutdown = false; | ||
/** | ||
Asynchronous wrappers for sqlite3_vfs and sqlite3_io_methods | ||
methods, as well as helpers like mkdir(). Maintenance reminder: | ||
members are in alphabetical order to simplify finding them. | ||
*/ | ||
* Asynchronous wrappers for sqlite3_vfs and sqlite3_io_methods | ||
* methods, as well as helpers like mkdir(). Maintenance reminder: | ||
* members are in alphabetical order to simplify finding them. | ||
*/ | ||
const vfsAsyncImpls = { | ||
@@ -777,5 +775,5 @@ 'opfs-async-metrics': async () => { | ||
/** | ||
ACHTUNG: this code is 100% duplicated in the other half of this | ||
proxy! The documentation is maintained in the "synchronous half". | ||
*/ | ||
* ACHTUNG: this code is 100% duplicated in the other half of this | ||
* proxy! The documentation is maintained in the "synchronous half". | ||
*/ | ||
if (state.s11n) return state.s11n; | ||
@@ -782,0 +780,0 @@ const textDecoder = new TextDecoder(), |
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
3108159
19
60312
9