Applying the dump from session extension will modify the db, so you need to copy all data to the node that will run sqlite, then apply changes, then start db. A COW system would allow you to to store the bulk of the data in a shared and network-mounted folder, and only copy over the changes since the snapshot was made. For us this could easily reduce copy-work several orders of magnitude. It is also easy to roll back any changes since snapshot was made by simply deleting files. This is relevant when running tests or working on new product features. Also, the snapshot-data would be read only, simplifying backups and the effect of data-corrupting errors.
Fredrik On Fri, Oct 4, 2019 at 3:44 PM Simon Slavin <slav...@bigfraud.org> wrote: > On 4 Oct 2019, at 12:17pm, Fredrik Larsen <frel...@gmail.com> wrote: > > > A copy-on-write IO-path where data is split into static and dynamic > parts (think snapshots for storage) would be very helpful for our project. > > SQLite abstracts changes-only tracking at the transaction level, and > provides it as the session extension: > > <https://www.sqlite.org/sessionintro.html> > > You can save your changeset BLOB however you want and do anything you want > to it including apply it to different databases on different computers. A > BLOB is just a sequence of octets. Handle it however you want. > > Providing the same feature at VFS level would be far more difficult > because different databases with the same data can be laid out differently > in different files on different computers. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
