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.
Benjamin.
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
