save bug

[Benjamin]

Kaaren Shalom & Richard Gilligan wrote:
> On Friday, September 19, 2003, at 11:46 AM, Derek Atkins wrote:
>> I dont know..  The real answer is to not require 'save on exit' at all
>> and be saving along the way.
> I don't know if it is the real answer.  But I am sure that it is an 
> unusual answer.  I don't use any applications that take that approach.  
> At first blush, it doesn't seem to provide the master/servant power 
> relationship that I want to have with my tools.  Gnucash's UNDO 
> capability would needed to be massively improved.

This is the norm for database-oriented applications. The concept of 
saving a whole database is a very strange one indeed. It's the norm in 
configuration management. It's the norm in programs like quicken. 
Instead of loading and saving files these systems allow you to make a 
change or set of changes, and then commit those changes thereby saving 
implicitly. Quicken "saves" the file every time you enter a transaction, 
in the sense that a crash or unclean exit won't lose your changes. The 
commit is effectively the save (although it can be implimented in 
various other ways depending on your backend). This concept of 
committing a set of changes instead of saving is more compabible with 
multi-user systems than making the saved view idential to the on you 
have in your program's memory.

My personal feeling is that the load-save concept is a strange paradigm 
that should be replaced by a load-commit concept across most 
applications. How many times after microsoft word has crashed have you 
wondered "where was I up to?" and had to reconstruct what you'd entered? 
  An auto-save facility can reduce the impact of a crash or unclean 
exit, but it doesn't solve the basic problem of a user entering data and 
having that data go the way of the pixies. A user should be able to 
enter data and know as soon as the transaction has "saved" that it will 
not disappear.

You've brought up the undo facility, and I think that's an important 
issue. In a word processor you certainly want to be able to undo and 
redo any number of changes to your data. You may want to compare 
different versions of the document. All these features are useful, and 
many translate to gnucash files. What's needed there is some kind of 
history of changes that can be rolled forwards and backwards whenever a 
user requires it. Perhaps more work can be put into gnucash in this 
area, but I think that the issues of explicit saving and undo/redo 
facilities are quite different, and I suspect that the undo/redo 
facilities aren't as critical in an accounting package as they are in 
word processing. While word processing may be an artistic effort 
requiring many rewrites, most changes in an accounting system are 
addition of new data. Undoing these additions is quite easy once you 
know which ones you want to dispose of: Just delete the transaction. 
Undoing a delete is trickier, of course, which perhaps implies that 
transactions should never be deleted only voided.

The other issue that comes into this is backups. If the program you're 
using is making changes to the file when you haven't commanded it to, 
perhaps its more likely to corrupt the file. Certainly the code to make 
some of this happen can get quite complicated and if you're rolling your 
own instead of relying on an established database technology you're 
running a risk. This risk may be mitigated by keeping a history of 
previous save files, so before any automatic save the old save file 
would automatically be renamed.

Anyway. My feelings on this issue are growing stronger. I think that 
gnucash should move (at least as a configurable option) to a 
database-like concept of managing the XML files, where data once entered 
is synched to disk in such a way that even a machine crash won't lose 
your data. This could be achieved using the log replay facility[1] 
combined with the current XML format where major events such as loading 
and quitting could roll the log file into the main file, or whenever the 
log file grew to 10% of the main file.

Benjamin
[1] With judicious use of fsync()