Thank you @PotOfCoffee2Go I ended up taking some of your code from #8101 to get this up and running. There's still some stuff missing (like the tests!) but it gets things moving.
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
This is the start of adding support for large attachments.
We have a new endpoint for POSTing tiddler data. The idea is that it will take any kind of data and figure out how to extract tiddlers from the upload and save them in the nominated bag.
The next step is to move the attachment files into a special folder and reference them from the database so that we can construct _canonical_uris for them.
