May not actually be needed

Avoids "string too long" errors when working with big tiddlers (>100MB)

Cannot yet specify the bags for the new recipe

Currently hard wired to kick in for tiddlers over 10MB (in base64 representation for binary tiddlers)

…iddler came

This commit fixes sync within hosted wikis

The motivation is to encapsulate knowledge of the SQL queries

…licitly

Otherwise changes to _multiwikiserver/ tiddlers are saved back to the file system

Perhaps it would work better to configure the wiki to sync state tiddlers to the browser.

Otherwise tiddlers containing `</script>` will break TiddlyWiki

…ils to load

...and use it to add an image for bags/recipes that do not have a $:/favicon.ico

…lete the UI for creating bags and recipes

Styling to come

…rchive

The archive format is a legacy format that I used with Xememex, and will need to be updated to iron out the wrinkles

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.

Thanks @hoelzro

To make us more tolerant of proxies that "helpfully" decodeuricomponent for us (looking at you Azure)

* 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

* 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

It appears that not all statements can be finalized.

@linonetwo the resulting archive should be suitable for storing in git

Useful for testing

Thanks @hoelzro