GDA: Transactions (was Re: Managing large files)
Andrew Sackville-West
andrew at swclan.homelinux.org
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
handwaving).
>
> 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.
A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080309/a7296a81/attachment.bin
More information about the gnucash-devel
mailing list