On Sat, Nov 20, 1999 at 12:21:59PM -0600, Rob Browning wrote:
> Christopher Browne <[EMAIL PROTECTED]> writes:
>
> > Rob Browning suggested that it might be good to have a way of
> > somehow handling calculations done in Guile; I think I have some
> > suggestions for architecture. Either better still, or scarier
> > still, my "strawman" proposal has not, to the best of my
> > knowledge, been implemented in any system.
>
> [...]
>
> > a) Transactions need to become "first class objects," with the ability
> > to attach to them a schedule on which they are to be repeated.
>
> I'll probably have more to say about this later, but I'm not sure I
> think that this needs to involve modifying the structure of
> transactions in the engine, thought it might need to involve modifying
> the data file format.
A much simpler, quicker and more reliable solution would be, IMHO, to
leave the account database as it is and simply add a second database
(i.e. structure in memory + file) containing nothing but the scheduled
transactions for this account. Transactions belonging to some scheme
could simply be flagged - not with an ID but simply as "automatic" or
something (I dimly remember somebody saying there is an unused bitfield
around). This approach has, I think, several advantages over using just
one file:
1) Data for a single transaction and data for some transaction scheme
(loans etc.) differ considerably. It seems quite appropriate to store
them in distinct files with distinct data formats, each suited to
its task. Besides, a single transaction and a loan scheme are really quite
different concepts that should only be mixed at our peril.
2) Accounts and scheduled transactions can easily be processed
separately, e.g. by conversion tools, external report generators
and whatever you like to think of. In return any tool designed
to automatically update accounts only has to look at the schedules
in order to determine whether anything needs to be done.
3) Reliability. Building parsers that act correctly in all circumstances
is not an easy task; especially not if you are dealing with objects
that can dynamically store information. In addition, dealing with
transaction objects of variable size is prone to make the transaction
engine less reliable. Just imagine a scheduling tool generating a
not-quite-correct transaction entry. A scheduling tool generating a
not-quite-correct schedule is far less dramatic, for it doesn't
affect the accounts directly. (Of course, coming from the OO-world
I am all for encapsulation of data wherever possible. :-)
4) It is more like real life. This need not be an advantage in itself,
but I usually find that it makes a programmer's life easier. Your
balance sheets show you transactions and balances. Full stop. Loan
schemes, depreciation schems and the like are usually stored on
different pieces of paper. Thinking of how I am doing this by hand, I
don't need to know about transactions when setting up a scheme like
this, nor do I need to know about my exact depreciation schemes to
understand that a transaction on my balance sheet is part of one. I
don't really see why an accounting program needs to know about both in
the same data structure, so to say.
5) Actually, it is what you would do in database design. Just create a
second table instead of adding fields to the first that will in most
cases remain empty, thereby adding needless complexity to your data
structures and the parts of your program handling them.
> I envision the system as having a "scheduling infrastructure", and
> your scenario would just be handled via code that would instantiate
> transactions when the right criteria are satisfied, rather than as a
> modification to the engine-level idea of transactions themselves. For
> example (definitely psuedo-code):
>
> (gnc:add-event '(days-of-month 1 5 21)
> (gnc:add-transaction ...
> other-transaction-details
> (compute-some-value
> (gnc:get-account-balance
> (gnc:lookup-account-by-name "SomeAccount")))))
>
> Of course something would have to be done to guarantee uniqueness,
> either some event tagging scheme or some locking semantics, but that's
> probably doable. And this sort of sounds like a job for "cron" or
> "at", but we probably can't use those. I don't think they have
> acceptable guarantees on execution or enough interface flexibility.
> We'll have to do something ourselves.
Indeed they haven't. Just think of somebody switching off his PC. cron
will not execute any task that should have occured meanwhile.
I also believe this is not necessary. After all, you do not need files
that are changed at a particular date or time. First time you really
need the change is when you next look at the files, meaning the accounts
could be updated upon startup. Uniqueness is - I think - guaranteed, too.
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.
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]
