Open MalignantCarp opened 2 years ago
The proposed solution to double-check database.json
for changes prior to writing to it has a major flaw. If the state of one of the objects has changed, such as setting a word goal or setting recording state, potentially to read-in of the changed file will overwrite those changes, so a logging mechanism for changes to the database would be required in order to preserve any change. The alternative, would be to run the check before doing anything that will alter the state. Thankfully, nothing toggles, so that sort of sync issue won't exist with that model. It's probably best to collect the ctime and mtime stats for the database on load and then use those as comparison. If either of them have changed, reload and reset the checks. All UI functions that allow changing of state will need to be reviewed, and the debounce function that does online word counting will need to run this check/load function prior to sending the text for word counting, as that will change object state.
If changes are made via
git pull
while Obsidian is running, statistics go out of sync as no changes made todatabase.json
via the synchronization are loaded into the running model. The easiest solution to this would be to read the contents ofdatabase.json
prior to saving and matching that to what was loaded. If the two strings are different, reload thedatabase.json
data and synchronize it with what is currently in the model.There are two major issues with this, however:
database.json
file was pulled from git but before an attempted write todatabase.json
that would trigger this re-sync, those changes could potentially not be captured. I don't see why this would be the case, but it is something to attempt to test to be sure.I assume these issues would be the same with Obsidian Sync.
Currently, the easiest solution to this is to run
git pull
prior to opening Obsidian.