GDA: Transactions (was Re: Managing large files)

Daniel Espinosa esodan at gmail.com
Mon Mar 10 20:27:35 EDT 2008


2008/3/9, Andrew Sackville-West <andrew at swclan.homelinux.org>:
> 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).
>

In multiuser enviroment is better to leave that work on the DB engine.

>
>  >
>  > 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.
>

May be QOF could be implemented as a set of GObject hierarchy and the
backend could be a GInterface.

Why?

Becouse the acutal QOF keeps a GHash of objects in memory, but in GDA
you could have a GdaDataModel for all objects, even using Iterators to
avoid have all in memory. Then leave the backend to manage its own
method, may for XML is Ok but not for GDA.

I think QOF could run queries over in memory objects, but in GDA you
run over the server, with a much powerfull set of SQL fashion. Then
leave the backend to manage its own queries search and allow the app
(GnuCash) to know if it can run powerfull or limited queries using,
like in GDA does for each server provider.

In the future QOF could be implemented to base its objects using GDA
directly, and or sustitude all the implementation to use GDA and allow
GnuCash to be a "db app".


>
>  > 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
>
> -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.6 (GNU/Linux)
>
>  iD8DBQFH1KGCaIeIEqwil4YRAsvRAJ92eLOx2BYAA43vnQz3SeoA85nOMwCgnyf1
>  8rRN2V9tJf3OuhcEun/6N3g=
>  =MLJn
>  -----END PGP SIGNATURE-----
>
> _______________________________________________
>  gnucash-devel mailing list
>  gnucash-devel at gnucash.org
>  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)


More information about the gnucash-devel mailing list