An easy simplification can be had if we were willing for the journal file to not be deleted (but truncated instead) when a writer is finished (meaning, it persists), then that file could double as the 'semaphore/lock' file which I said could be added. So cut one zero-length file.
Ultimately, my idea requires a minimum of 3 files:
- the 'main' file
- the 'journal' file to hold a transaction being constructed
- the 'commit-flag' file whose existence is soley what determines whether or not we have an inconsistency
A main benefit I see of my solution is that they are fully backwards compatible with older SQlite code (with occasional trivial human or application intervention), since the internal formats of the main and journal haven't changed. So files can be passed back and forth between different versions. (Also useful during development of new feature, in case a bug is discovered and users are recommended to go back to an older version while it's sorted out.)
The use of the separate 'commit-flag' file saves the internals of the two older files from being changed. If backwards compatability wasn't necessary, then the 'is-committing' flag could be put in the journal file and that file be read for the consistency check rather than the separate file. But older SQlite can't use it, and it is no longer easy for a human or application to do the manual check.
As for the suggestion of replacing the journal file with a 'sparse copy' of the main file, which puts work on the file system but makes the SQlite code simpler, I can agree with this, though I would consider it a separate design decision, and older SQLite wouldn't understand that journal format.
Questions? Feedback?
-- Darren Duncan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
