…otherwise we may end up in a situation where we're always stuck in an
"already in a transaction" state and often neglect to actually enter a
real transaction!
* Switch from better-sqlite3 to node-sqlite3-wasm
Seems to be slower, but might make cloud deployments easier by not having any binary dependencies
* More logging
* Temporarily use a memory database
We will make this configurable
* Revert "More logging"
* Resume loading demo tiddlers
* Cache prepared statements
Gives a 20% reduction in startup time on my machine
* Some more logging
* Update package-lock
* More logging
* Route regexps should allow for proxies that automatically decode URLs
Astonishingly, Azure does this
* Go back to a file-based database
* Less logging
* Update package-lock.json
* Simplify startup by not loading the docs edition
* Tiddler database layer should mark statements as having been removed
* Re-introduce better-sqlite3
* Make the SQLite provider be switchable
* Support switchable SQL engines
I am not intending to make this a long term feature. We will choose one engine and stick with it until we choose to change to another.
* Adjust dependency versions
* Setting up default engine
* Make transaction handling compatible with node-sqlite3-wasm
https://github.com/tndrle/node-sqlite3-wasm doesn't have transaction support so I've tried to implement it using SQL statements directly.
@hoelzro do you think this is right? Should we be rolling back the transaction in the finally clause? It would be nice to have tests in this area...
I looked at better-sqlite3's implementation - https://github.com/WiseLibs/better-sqlite3/blob/master/lib/methods/transaction.js
* Default to better-sqlite3 for compatibility after merging
* Use transactions when modifying multiple resources
This prevents partial changes from entering the database, and also
nets a nice speed-up.
* Keep track of transaction depth
…so we could someday potentially leverage SQL implementations that don't
implement nested transactions
