On 27 Feb 2000 14:52:54 CST, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
> Dave Peticolas <[EMAIL PROTECTED]> writes:
>
> > This is something that deserves some discussion, because the
> > solution is not entirely clear. Somehow, we should associate
> > the account-expanded state with each gnucash file, but we
> > shouldn't save the information in the actual file itself,
> > since GUI info isn't supposed to be there, and it would
> > make it difficult for multiple users to share the file.
> >
> > We could have a separate file that is saved in the same
> > directory for each user, but that seems a bit messy.
>
> As a more radical alternative, we could switch to using a directory
> per account group rather than a file, and it could contain whatever
> files we need in order to carry all the right state around when the
> account group is copied, moved, etc:
>
> my-finances.gnc/data
> my-finances.gnc/state.user1
> my-finances.gnc/state.user2
> my-finances.gnc/lock
> my-finances.gnc/pending-transactions
>
> etc. This would allow us a substantial amount of flexibility now and
> in the future, but it might be kind of strange to most people. ISTR
> that NeXT did something like this instead of Apple's resource/data
> fork hack.
Way back when, I suggested the idea (that was rebuffed as "fairly insane") of
having a directory for each transaction; I'm happy to see a proposal that
heads in the right direction, at least moving to have multiple files.
Not moving back to "fairly insane," I'd nonetheless suggest a bit more
"paranoid" structure; feel free to improve on it as you like:
my-finances.gnc/accounts.latest
my-finances.gnc/accounts.previous
my-finances.gnc/accounts.pending-user1
my-finances.gnc/accounts.pending-user3
my-finances.gnc/accounts.work-user1
my-finances.gnc/accounts.work-user2
my-finances.gnc/accounts.update-user1
my-finances.gnc/txns.log
Similarly:
my-finances.gnc/txns.latest
my-finances.gnc/txns.previous
my-finances.gnc/txns.pending-user1
my-finances.gnc/txns.pending-user2
my-finances.gnc/txns.pending-user3
my-finances.gnc/txns.work-user1
my-finances.gnc/txns.work-user2
my-finances.gnc/txns.work-user3
my-finances.gnc/txns.update-user2
my-finances.gnc/txns.underway
my-finances.gnc/txns.log
Contents:
[whatever].latest is the latest updated set of data across all users.
[whatever].previous is a previous version of the "total data."
[whatever].underway is a new version of "total data" that is being created
based on [whatever].latest + all the pending work.
[whatever].work-user1 contains the set of transactional updates being worked
on by user1.
[whatever].pending-user1 contains the set of updates to [whatever] that user1
has completed and requested to "commit" into the system. They are *NOT* in
txns.latest yet.
[whatever].update-user2 contains updates that *were* pending, but which are
now in the process of being added to [whatever].latest
[whatever].log is a log file that lists all transactions that have been
committed into [whatever].latest since [whatever].previous
This approach involves two kinds of processes:
a) User processes.
The "user" processes read overall state from [whatever].latest, and write out
transaction data to [whatever].work-userid. Once updates are done, they push
the data to [whatever].pending-userid. [If there's already a file there, it
may be necessary to make a series of "pending" files.]
b) Data Manager.
The data manager is the single central process that gets to update the
"database" (e.g. - txns.latest).
Its behaviour would be thus:
1. Wake up.
2. See if there are any "pending" files.
If so, rename them to "update".
Thus:
mv txns.pending-user1 txns.update-user2
3. Open txns.underway as a new database.
4. Run through all the "update" files, and update txns.underway based on
what's in the "update" files.
Append each update into txns.log. That way, if something blows up, we can
take txns.latest, run through the transaction log, and safely bring it all up
to date.
5. Close txns.underway.
6. New generation of txns.latest
--> mv txns.latest txns.previous
--> mv txns.underway txns.latest
--> rm *update*
7. Go back to sleep.
Note that this should scale Rather Nicely, even on NFS...
--
"We use Linux for all our mission-critical applications. Having the
source code means that we are not held hostage by anyone's support
department." -- Russell Nelson, President of Crynwr Software
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
