GDA: Transactions (was Re: Managing large files)

Andrew Sackville-West andrew at
Sun Mar 9 22:48:34 EDT 2008

On Sun, Mar 09, 2008 at 08:10:34PM -0400, Phil Longstaff wrote:
> Andrew Sackville-West wrote:
> > On Sun, Mar 09, 2008 at 06:35:01PM -0400, Phil Longstaff wrote:

> >> My proposed (temporary?) solution is to modify the gda backend to load
> >> all transactions and splits at startup time.  Since all data will be
> >> loaded, I will also (temporarily?) disable query processing so that qof
> >> queries will operate on in-memory data.
> > 

> It probably involves quite a few changes, some of which could be hidden
> at the expense of some performance.  For example, currently, the only
> way that transactions and splits are loaded with the gda backend is via
> a query when a register is opened.  The backend grabs all splits for
> that register, then gets a list of the parent transactions, then all
> splits for those transactions.  This will mean that the specific
> account's split list is complete, and other accounts' split lists may
> have a few splits on them.  In the register, this query is run over and
> over again (possibly a bug in the register?).  We could modify the
> xaccAccountGetSplitList() call to automatically run the split query for
> the account so that this call would always return the correct list. 

huh. I clearly need to research the whole backend more (I think that's
obvious ;). So I always viewed is as sort of what happens
already. That is that the current xaccAccountGetSplitList(), returning
that list, would get it from a QOF query and that implementing the gda
backend was a simple matter (much handwaving) of redirecting that
query to the appropriate backend. Is that not what happens? or is it
just a matter of implementation? That is that it is the logical step
to take it just hasn't been taken yet. 

> In
> the future, a real db app, rather than getting the full split list and
> scanning through it, might ask for the sum of all amounts for splits in
> a certain account between certain dates (and the db backend can do this
> work and return a single value).

this would be nice, but probably depends on performance. Is the db
engine faster at this than we can be? and if we're getting a SUM is it
reasonable to assume we'll need the list as well, so we save queries
by getting the list and keeping it lying around for the next use (more

> I don't know what is the optimum development path to get from where
> gnucash is to a full db app.  QOF does allow queries to be created and
> executed, but I believe those queries only return lists of objects and
> can't include functions like SUM (I don't really know). 

If we no longer keep our own version of QOF, I would imagine we could
do it again to extend it in these ways.

> I also don't
> know how much of the QOF query mechanism is exposed to scheme code.
> Maybe some of the reports should be re-written so that, for example, the
> basic income/expense report could use better qof queries (return the
> list of all splits where account = "AccountBeingLookedAt" and tx_date >=
> start date and tx_date <= end date) or even better (return SUM(amount)
> from all splits where ...).

ISTM that the best case is to just implement the xacc* functions so
that they work with either backend and the reports could remain as
they are and operate with either backend. 

very much .02 of some heavily devalued currency.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : 

More information about the gnucash-devel mailing list