Richard Wackerbarth writes:
> I'm not sure that the "append-only" aspect works. Even the "pen and ink"
> accountants could modify entries by drawing a line through them.
She is careful not to obliterate the corrected entry: this can be viewed as
shorthand for adding a correcting entry. That is how I would handle this:
a correcting entry with a pointer to the corrected entry would be appended.
The front end would hide this during normal use, so that it would appear to
the user that he was editing the entry.
> Much of what you want can be accomplished by storing the active records
> in a file and storing that file in an appropriate file system.
I don't see that.
> The convenience of a single file datastore is offset in many cases by the
> security, efficiency and reliability of multiple files.
I'm not after convenience, particularly.
I don't see how a fixed record length append only file of posted journal
entries would be less secure than multiple files (use an encrypted
filesystem if you are paranoid). With the record number as the key,
finding a particular fixed-length record is as fast as a seek: what's more
efficient? An append-only file written to only by one simple process
should be quite reliable and just about immune to being scrambled by a bug
in the software. With each record containing a copy of its record number
data could be recovered even from a scragged disk.
However, this is notion of mine is a bit off-topic: it would require that
the basic data structure of gnucash change from the 'split' to something
more like a canonical journal entry, complete with two posting references.
Not likely. I think.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
