How to do autosaving (commit data to disk) within an transaction?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How to do autosaving (commit data to disk) within an transaction?

Robert M. Münch
When the user opens a file I start an outer-most transaction to be able to revert the file. So far so good.

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.

But how can I commit stuff to disk, while an outer-most transaction is open? Is there something like an „UPDATE IMMEDIATELY…“ or so to bypass an open transaction? How would one do this?

I would like to avoid using a 2nd database-file if possible.

--

Robert M. Münch

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

signature.asc (537 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to do autosaving (commit data to disk) within an transaction?

Simon Slavin-3
On 29 Jul 2018, at 12:56pm, Robert M. Münch <[hidden email]> 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>

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.  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.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: How to do autosaving (commit data to disk) within an transaction?

Robert M. Münch
On 29 Jul 2018, at 14:07, Simon Slavin wrote:

> On 29 Jul 2018, at 12:56pm, Robert M. Münch <[hidden email]> 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

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

signature.asc (537 bytes) Download Attachment