#RMV11 Any idea what the new temporay files are for?
does it sound like the two new files (or database use of) could potentially be used for a rollback / undo future feature?
Gemini said following when asked:
How WAL Enables Rollback and Recovery
The WAL mode in SQLite works by preserving the original, unchanged data in the main database file and appending new changes to a separate file, the WAL file (e.g., my_db.db-wal).
The Role of the SHM File
The Shared-Memory (SHM) file (e.g., my_db.db-shm) is primarily used as an index and for coordination between multiple connections accessing the database in WAL mode.
Key Differences from Traditional Rollback Journal
In contrast to the older default mode that uses a rollback journal, the WAL file contains new data that has yet to be applied to the main database file.
Quote from kevync on 2025-10-12, 10:11 amdoes it sound like the two new files (or database use of) could potentially be used for a rollback / undo future feature?
Not any moreso than the Journal file. I suspect an Undo feature would have to be built on top of SQLite in the application. Whether it could or would use either the Journal or the WAL file is beyond me but I doubt that it should - sounds risky. Family Tree Maker 2019(?) has a 1000 step Undo but uses encrypted SQLite so it's not possible to see if there are any tables in its database to support Undo.
I'm writing to agree with Tom. If RM were to implement an Undo, it would need to be done totally by the RM app, not depending on SQLite journal file or wal file.
The Gramps package uses SQlite and it supports an Undo. However, the Gramps implementation of Undo is based on an in-memory Undo Stack / Redo Stack. If the Gramps app crashes or if the system crashes, then the in-memory stack is lost and an Undo is not possible for the transactions for that Gramps session. The stack is also lost upon normal termination of Gramps.
In theory, RM could do the same thing. Or it could even do Gramps one better by storing some sort of Undo Stack / Redo Stack on disk, possibly even as a table in the RM database. But it's very hard to see how RM could use either the Sqlite journal or the WAL file for this purpose. Those files serve a totally different purpose, and they operate asynchronously of and transparently to the RM app itself.
just curious. Yes FTM 2019 (and 2024) both have "undos" and they can work -- but the might not always work to fix sync failures. There have been a few times which something I did was bigger 'ohoh' in RM - such as merging two placenames that should not be. There is always recover but sometimes it tradeoff.
I knew Gramps was Sqlite (and open) but did not recall it had undo.
Those files serve a totally different purpose, and they operate asynchronously of and transparently to the RM app itself.
I guess that makes sense. I guess the biggest risk is understanding open any (2) APPs at same time connected to same db. Instead should now be separate. Additionally those files also suggest that could service backups including OneDrive as most riskier.