Log replay facility

Benjamin 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 mailing list