human readable in preparation to add data-title=<<listItem>>
for better UX defining a "read only" theme
Changes to be committed:
modified: core/ui/EditTemplate/controls.tid
modified: core/ui/PageControls.tid
modified: core/ui/PageControls/more-page-actions.tid
modified: core/ui/ViewTemplate/title.tid
modified: core/ui/ViewToolbar/more-tiddler-actions.tid
modified: plugins/tiddlywiki/menubar/items/pagecontrols.tid
* Fix a few typos
The "database instead of store" change isn't a typo fix, per se, but
these tests are testing the lower-level database layer, and I'm about
to introduce some tests for the higher-level store layer, so I want to
avoid any confusion in the test names
* Start on SQL store-level tests
* Add some tests for createBag
* Add test for getBagTiddler and getBagTiddlers
* Add basic recipe tests
* Add a test for saving a tiddler within a recipe
* Add store test for deleteTiddler
…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
