Re: [sqlite] 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  
> 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: 
> 

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

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

[Simon Slavin]

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



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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] 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


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