Log replay facility

[John Reynolds]

(moving this message to the User list for greater feedback)

Your ideas seem like good ones. I wonder what others think. After disscussion, 
if the ideas for feature improvement can be distilled, you should open a 
bugzilla report to capture them.

John R.

On Thursday 18 September 2003 01:42 am, Benjamin wrote:
> G'day,
>
> 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
> gnucash-devel at lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel