On 29 Jul 2018, at 14:07, Simon Slavin wrote: > On 29 Jul 2018, at 12:56pm, Robert M. Münch <robert.mue...@saphirion.com> > wrote: > >> I want to add an autosave feature that stores some data at critical >> points/specific intervals. This data of course should be commited to disk, >> to survive any app crashes. > > Use a SAVEPOINT instead of COMMIT: > <https://www.sqlite.org/lang_savepoint.html>
That won’t help. SAVEPOINTS are for undoing things. I want to write one thing definitely to disk to have it available in case of a crash. If the app crashes, all SAVEPOINTS are gone. > Your use of an open transaction here is sort-of abuse of how SQLite works. > You have no real control over what is flashed to disk. I do, that’s why I use an open transaction. In this case, everything is flushed into the .journal file, which is automatically rolled back if it exists on the next app start. > Rather than relying on side-effects of transactions it might be better to > make your own data structure which reflects which tranche of data a > transaction is in. Beside the brute force approach of copying the unmodified file before opening and changing it (without a global open transaction than) the session extension seems to be the way to go. So creating changesets which are removed on user save. If the app crashes, the user can choose to start from the last manual save point or from the latests point minimizing data loss. -- Robert M. Münch
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
