Transaction Engine

[Christopher Browne]

On 05 Jan 2001 10:38:42 EST, the world broke into rejoicing as
Derek Atkins <warlord@MIT.EDU>  said:
> Christopher Browne <cbbrowne@smtp.hex.net> writes:
> 
> > Notably:
> > a) Balance management [the thing of keeping track of daily balances,
> >    or perhaps based on some other granularity];
> 
> I think part of the proposal was to checkpoint the balances within the
> database.  Then the UI can compute running balances from the last
> checkpoint.  Granted, this requires the UI to grab all the
> transactions since the last checkpoint, which may or may not be an
> onerous task.  So, it is unclear if the gnc_server would actually
> handle this task.

Managing where the checkpoints are is almost certainly out of the scope
of what one would reasonably expect of (say) PostgreSQL triggers/rules.
Attaching balances to the checkpoints would either require rules/triggers,
or that they be managed somewhere in the "gnc_server."

If the checkpoints were managed explicitly in the "gnc_server," this
would take _all_ the heat off the DBMS so that we could use MySQL or even
perhaps Berkeley DB as "relatively featureless, but easy to install/embed"
options.

> > b) Event management; telling GUIs when [say] a balance on which the
> >    present screen depends, or when one of the transactions on screen
> >    have changed.

> Well, yes, this is certainly "outside" to DB.  I was considering this
> part of the role of the gnc_server, to send client notification events
> when data changes.

I would gently suggest the thought that if there are a bunch of
different things to manage, it may be logical to have multiple processes.

Note that ORBit, part of Gnome, comes with an Event Service
implementation; it would be a not-overly-outrageous idea to consider
using that as an event manager, seeing as how that is what it was
designed for...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
<http://www.hex.net/~cbbrowne/>
What would a chair look like, if your knees bent the other way?