On Thu, 25 Nov 1999 13:41:50 +0100, the world broke into rejoicing as
Jan Schrage <[EMAIL PROTECTED]> said:
> On Mon, Nov 22, 1999 at 08:59:42AM -0600, Christopher Browne wrote:
> [large parts snipped, for I agree with them :-) ]
> > Note that CBB uses the same syntax for specifying events as does
> > cron/at; even if we use none of the same code, it might still be a very
> > good idea to use the same syntax, as it is already well-understood.
> >
> I think this needs, at least for events belonging to some transaction
> scheme, the small extension of an ID. That way, if you have to edit an
> existing transaction scheme (say your tax authority does not quite agree
> with your depreciation schemes) you can easily identify the events
> belonging to this particular scheme and change/delete/... them.
> This would imply that transaction schemes and events are different kinds
> of objects and be stored in different tables. Events can (and will) be
> generated from schemes, but not vice versa. They need not, of course,
> belong to a scheme.
Having a "transaction walker" that can identify transactions based,
for instance, on the "memo" field, is something that certainly has merit.
I don't think they need to be as separate as you seem to be indicating;
I suggest reevaluating this when there is a "transaction scheduler,"
as it is fairly possible that it would support what you're thinking
of here.
> [snip]
>
> > There are two problems:
> > a) Identifying that a transaction is already on the system, or not.
> > This corresponds more or less to my comment that it would be nice to
> > have something like a CORBA IOR for each transaction.
> >
> > A present weakness of GnuCash that has been causing me to be a bit
> > uneasy for rather a while is that it has no "transaction table," as
> > well as the consideration that transactions do not have any
> > system-created identifier that is permanent across sessions. That is
> > a normal thing to see happen with transactions in "traditional"
> > accounting systems.
> Yes, that would certainly be a nice addition.
>
> > b) Being able to update the "database" from offline at the same time
> > that someone is running GnuCash.
> >
> > > I think this, as well as the rest of your mail suggesting a server
> > > process, really implies that a computer be up and running all the time.
> > > For a number of gnucash users that will not be the case. Thinking of a
> > > client-server system means gnucash will be playing in a different league
> > > of accounting systems. In that case I would also suggest moving to RDBMS
> > > for the storage of accounting information. Ah, well, perhaps we should
> > > stick to the way its going now at least for a while.
> >
> > There lies the crux of one of the big issues; I *disagree* that moving
> > to RDBMS would be appropriate; an appropriate move might be to an embedded
> > DBMS, with some tools to extract the data out to an RDBMS.
> >
> Since I brought it up...I don't like the notion of an RDBMS backend
> either. However, there are many people who have thought hard about good
> ways to store data, and we should use that expertise (e.g. by way of an
> embedded DBMS, as you suggest).
I suspect that the best way of making use of a DBMS is really by using
a purely-in-memory one (visions of Intersys Cache, or Times Ten, or the
Russion package "FastDB/GOODS" that's free), having the serialized version
be text, reading into memory those portions that need be in RAM, and
dumping to disk a transaction log.
In effect, everything on disk is text, but there can be considerable
sophistication in what is done in memory.
The critical issue is that jumping all the way to an SQL RDBMS provides
considerable complexity and some performance costs that I don't think
we want to need to cope with.
> > But a certainly thorny issue is that of finding a way of having external
> > processes have a way of getting data into the system whilst
> > - Gnucash might be running, or
> > - Gnucash might *not* be running at all.
> >
> > That being said, what comes to mind as a resolution to *both* would be
> > some sort of transaction queueing system, where external processes would
> > marshall data, and push it to some little GnuCash process that would drop
> > that data into some form of "queue" where it could wait until the main
> > GnuCash process would get a chance to get around to dealing with it.
> > Should that be:
> > a) Ten seconds from now, when you click on a "recalc" button at which
> > point GnuCash checks to see if any changes are queued, or
> > b) 8 days from now, when you start up GnuCash, and it pops up a dialog
> > indicating: "42 transactions queued up offline. Would you like to
> > review them before they get inserted?"
> >
> > Interesting thing... If there is a transaction recurrance scheme, and a
> > text-based way of storing recurrances, then this makes it quite natural
> > to queue external updates by building a file of one-time recurrances,
> > and queueing them up as needed.
> >
> > In other words, solve one problem and you may solve them all...
> Hmm..see my above comment on the distinction of singular events and
> schemes. For queueing and simple events this method is rather nice,
> but...
> If you set up complicated transaction schemes (for depreciation, loans
> etc) you will want a way to edit them later on.
Oh yes, you may want to edit them later on.
--> In cbb, the transactions that got "scheduled" are marked with a
special reconciliation flag, "?", that provides a way to recognize
that they are "scheduled," and thus are fair game for automated
rewriting.
Extracted from recur.pl...
#-----------------------------------------------------------------------
# Traverse all transactions and perform the following steps on entries with
# $cleared = "?":
#
# 1. If date has passed, change $cleared to "!"
# 2. If date is present or future, delete entry. These entries will be
# reinserted later.
#-----------------------------------------------------------------------
--> If parts have gotten reconciled, you're Out Of Luck, as it's just
plain Not Safe to modify data that has been thereby verified as
correct.
That is resolved by the above "Traversal Rule."
I think this obviates your need for "schemes."
> - When a scheme is created, it is stored in "schemes". At the
> same time all future events belonging to this scheme are created
> and stored in "events", flagged with some ID / sub-ID. I.e. if
> you use 32 bits for a transaction ID, reserve 10 or 12 of them
> to identify the scheme a transaction belongs to.
Of many possible ways of managing this, reserving a few bits inside
another field is *not* one of the ways I'd want to contemplate. If
there is a need for a field to support this, then we add a field to
support it.
Many of the "Y2K"-like problems have arisen because people have hacked
functionality in by faking part of a field to do something it wasn't
intended to do. This is something that GnuCash certainly does *not*
need to do.
> - When a scheme needs to be edited, the transactions already stored in
> the accounts can be identified and updated (issuing dire warnings to
> the user) using this ID, the event table likewise.
>
> The whole purpose of this is really to ease later editing.
> It's probably not the only way, but I think it's more flexible than
> a cron-like scheme only.
The *critical* underlying thing is to have some scriptable scheme to
create/modify/delete transactions. Given that, *anything* is possible.
Walk through the transactions, and rewrite whichever ones you like.
I suspect that you're underestimating the power of a cron-like system,
as that should, by itself, be remarkably powerful, and easier to make
use of than an "infinitely powerful scripting system."
--
"My theory is that someone's Emacs crashed on a very early version of
Linux while reading alt.flame and the resulting unholy combination of
Elisp and Minix code somehow managed to bootstrap itself and take on an
independent existence." -- James Raynard in c.u.b.f.m on nature of
Albert Cahalan
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
