On Tue, 27 Jun 2000 22:26:04 EST, the world broke into rejoicing as
Glen Ditchfield <[EMAIL PROTECTED]> said:
> On Mon, 26 Jun 2000, Dave Peticolas wrote:
> > This is the second version of the backup proposal.
> > ...
> > When GnuCash starts, it should check for the presence of the log file
> > and, if it exists and has a later modification time than the main
> > file, GnuCash should prompt the user to load the log file in addition
>
> I don't want to trust file modification times; sometimes they get changed. H
ow
> about logging 'save' events, with matching timestamps or some such in the
> saved database and the log entry? When GnuCash starts, it checks the log. I
f
> the last entry isn't the 'save' for the database, something went wrong.
This is a pretty good idea.
> > + GnuCash should maintain log histories, rather than save histories, to
> > handle failure #3.
> >
> > After saving, the current log file should be renamed to be the first
> > log history file, and a new log file should be started.
>
> Wouldn't it be simpler to have just one log file, and keep appending to it?
> Fewer file operations means fewer opportunities for disaster. Logging, log
> loading, undo, and miscellaneous scheme utilities would be less complicated
> because they won't have to handle multiple log files, some of which could be
> missing. (But you would need to give users a way to chop the front off of th
e
> log when they want their disk space back.)
Counterpoint...
Consider Oracle Archive Logs, which serve the _same_ purpose in the context
of Oracle databases.
There are several conditions under which Oracle will switch logs:
a) There is a "size limit;" commonly, you'll switch logs every 20MB or
at some such level.
This allows moving the logs out to tape periodically.
b) When you begin a "backup," which corresponds, in our context, to
"beginning to save a new full file," Oracle generally _switches_ logs.
This allows processing to continue; updates that take place during the
backup will be recorded in a "during-the-backup" archive log.
c) When you end a "backup," there is another "log switch."
That's perhaps more sophistication than we need.
But I'd consider having, rather than merely a log file, a log directory,
and provide the _option_ of splitting the logs off in some sort of
"regular" manner. Whether that's every 5MB, or one each day, or week,
it would be somewhat attractive to distinguish between the "old ones we
don't touch no more" and the "present one."
A recovery option that _I_ like (off top of head...) would be to allow
the gentle user to use "cat" to catenate together whatever old logs
appear relevant, into one log, and then for GnuCash to be able to read
from that log, perhaps with some control kept over this. Options
that would be nice:
--> May want to include a "save" file (e.g. - not a log file), or not...
--> Want to replay the items from the "catenated log file," perhaps
with the option of choosing start and end times.
If log items are time-stamped, then the person doing recovery could
manually strip off the log items before and after the desired
range.
"Here I am, in vi, at the start of what I want...
:1,.d
"Here I am, in via, at the end of the desired portion...
:.,$d
But it's nice if GnuCash can be used to select the start/end times,
and do this without the user having to mess around with files
directly.
The other "cool" thing that needs to be possible would be to take the
whole set of logs...
"cat logs/* > FULLTXNS; gnucash --loadlogs FULLTXNS"
and thus load in transactions straight from the logs, starting from
the beginning of time, and replaying the transactions in order, into
the engine.
I used this very facility in CBB, by the way...
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/linux.html>
Rules of the Evil Overlord #5. "The artifact which is the source of
my power will not be kept on the Mountain of Despair beyond the River
of Fire guarded by the Dragons of Eternity. It will be in my
safe-deposit box. The same applies to the object which is my one
weakness." <http://www.eviloverlord.com/>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
