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.
[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).
> 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.
One way of doing this might be to
- have two tables instead of one: "schemes" and "events" where
"schemes" stores depreciation and mortgage schemes and the like
"events" stores recurring transactions that can be specified in
a cron-like fashion.
- A recurring (or single future) transaction is stored in "events".
- 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.
- 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.
Comments...?
Jan
.. . .. .... .. . ... .. . ... ... ... .. ... ...... ... .. .... ........
Jan Schrage [EMAIL PROTECTED]
http://www.unix-ag.uni-kl.de/~schrage/
PGP Public Key: http://www.unix-ag.uni-kl.de/~schrage/pubkey.asc
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
