Log replay facility
benjamincarlyle at optusnet.com.au
Thu Sep 18 16:42:46 CDT 2003
I'm pleased to see the log replay facility working for gnucash. For
those who might have missed how to access it, it's a menu option to
apply the log under File|Import|Replay GnuCash .log file. This opens a
dialogue asking for the file to replay and after one is selected the
changes made in the log are applied to the live data file.
I'd like to make a few comments about this.
Firstly I think the ability to replay arbitrary log files is a good one.
I think the feature should stay and it appears can be used for advanced
file recovery. Additionally, I'd suggest a more user-friendly approach
for people like me who aren't so familiar with the contents of the file.
I'd suggest something like a dialogue that opens during the file loading
procedure after a gnucash crash with text like "It appears that your
gnucash file was not saved during the last session. Gnucash has
preserved the unsaved changes. Would you like to (.) keep the unsaved
changes or ( ) restore the last saved state. To stop seeing this message
make sure that you save your gnucash file before exiting". If "restore
the last saved state" is selected the file would be loaded and no
further actions would be taken by gnucash, but if "keep the unsaved
changes" is selected the last log would be applied on top of the
restored data. Naturally this would only be required for the XML file
format, and some kind of marker would have to live in either the saved
file or (my preference) the log file indicating that it contained
unsaved data (a new log file is presumably started each time save is
performed, right? Hmm.. I guess you'd probably have to either force a
save after a restore or keep appending to the old log after a restore so
that a sequence of crashes between saves would still return the proper
results. Are these complications part of the reasoning for the current
interface? I guess my preference for the overall behaviour would be to
make it as close as the database mechanism as possible to avoid having
to retrain just because the backend has switched. The simplest approach
to this might be to do away with explicit saving completely, keep only
one log, and save implicitly either at some event such as startup or
shutdown, or whenever the log file got too big, say 10% of saved file size).
To recount my story after hearing about the log replay facilty I updated
to 1.8.7, made some changes in the register, then killed guile with a
SIGSEGV. I expected the sort of dialogue I described, but instead the
data was simply loaded from the last save file. It took several openings
and closings of gnucash before I worked out what I needed to do to
restore the log files, and by this stage several log files had been
written after the one that contained my changes. This meant I had to
grep through the log files to find the one that I needed to apply before
actually initiating the change :) I just wouldn't like a
non-commandline-savvy user to have to go through that process too often.
In a related note after I restored the log file the register was updated
correctly, but at first impression I didn't think the change had worked
because from the accounts view no change was visible. I believe this is
a bug. The change I made for the test intentionally put one of my
accounts in the red so I could easily see it, but the accounts view
retained the last account total until I saved and re-opened the file.
More information about the gnucash-devel