3 ms·

> your changes will be physically written to disk, but they won't actually replace the old version from a reader's perspective until you explicitly commit This

by cesarb 6y ago

> your changes will be physically written to disk, but they won't actually replace the old version from a reader's perspective until you explicitly commit This breaks one important invariant: unless the user clicks "Save", the original file must not be modified in any way. It doesn't matter if the changes are ignored by readers; if "Save" is a separate operation, it's the only place which should modify the original file. Also, how would this work with "Save As"?

teraflop 6y ago
> This breaks one important invariant: unless the user clicks "Save", the original file must not be modified in any way. SQLite's default rollback journaling mode doesn't satisfy this property, but WAL mode does: updates will be first written to the WAL file, and automatically copied to the main database file only after at least one transaction has committed. > Also, how would this work with "Save As"? SQLite also has a "backup" API that I think could be used for this purpose: https://sqlite.org/backup.html https://sqlite.org/backup.html
krisoft 6y ago
I don’t understand what you are asking. When the user clicks “Save” that’s when your application calls the sqlite api to update the database. When the user clicks “Save as” the application calls the sqlite api to create a new database file, it then creates the database schema and dumps the internal representation of the document into it. You might be confused by the GP comment. It says that if something bad happens with the computer after your application started saving, but before the transaction is commited then the database still will be in a consistent state. (Altough the document will be in the pre-save state.) If the application is the “click save” kind then here we are talking about what happens if the power goes out in that fraction of a second after you hit save, but before the cursor stops being a hourglass.

by cesarb 6y ago

teraflop 6y ago

> This breaks one important invariant: unless the user clicks "Save", the original file must not be modified in any way. SQLite's default rollback journaling mode doesn't satisfy this property, but WAL mode does: updates will be first written to the WAL file, and automatically copied to the main database file only after at least one transaction has committed. > Also, how would this work with "Save As"? SQLite also has a "backup" API that I think could be used for this purpose: https://sqlite.org/backup.html https://sqlite.org/backup.html

krisoft 6y ago

I don’t understand what you are asking. When the user clicks “Save” that’s when your application calls the sqlite api to update the database. When the user clicks “Save as” the application calls the sqlite api to create a new database file, it then creates the database schema and dumps the internal representation of the document into it. You might be confused by the GP comment. It says that if something bad happens with the computer after your application started saving, but before the transaction is commited then the database still will be in a consistent state. (Altough the document will be in the pre-save state.) If the application is the “click save” kind then here we are talking about what happens if the power goes out in that fraction of a second after you hit save, but before the cursor stops being a hourglass.