GDA: Transactions (was Re: Managing large files)

Andrew Sackville-West andrew at swclan.homelinux.org
Sun Mar 9 19:29:06 EDT 2008


On Sun, Mar 09, 2008 at 06:35:01PM -0400, Phil Longstaff wrote:
> Derek Atkins wrote:
> 
> > GnuCash itself wont use an RDBMS as a real DB, but rather it'll just
> > use it as a data store, just like any other data store.  IOW, GnuCash
> > will still want to load all the records into memory every time.  This
> > is just the way GnuCash/QOF currently works, so comparing it to a "real
> > DB App" just isn't a fair comparison because, frankly, GnuCash ISNT
> > a "real DB App".
> 
> Which brings me to the next topic.  Currently, I'm trying to have the
> GDA backend load only what is needed on startup, and then load
> transactions and splits only when they're needed (when a register is
> opened).  There are a number of issues which might or might not be
> easily solvable:
> 
> 1) In the account tree, all balances are 0, even though I try to
> calculate the balance, cleared balance and reconciled balance and set
> them in the account using g_object_set().
> 2) When a register is opened, the running balance is always 0.
> 3) I haven't tried yet, but I would imagine reports will be wrong
> because they won't do what is required to force transactions or splits
> to be loaded.
> 
> 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.

This mimics what currently happens with the xml file, so I don't think
that's a problem, though I was looking forward to not having to wait
through my load times...

Does that mean that there would essentially be two copies of the
books? one in memory and one on disk with the disk version being
updated in sync with the memory version? If that doesn't happen pretty
quickly then we run into the same problem we currently have with lost
txns in unsaved books. It also allows the introduction of subtle
errors in that those two copies could drift apart leading to an
inconsistent state. 

Personally, I like the idea of using the db backend as a real db, with
every action being committed to the db on the fly and storing the data
on disk except for the currently used queries. At some point, it
will become a case of needing more devs focusing on getting gda up to
par with the current implementation. I assume we want to eventually
migrate over to all gda all the time. I *personally* would be okay
with a released version with a gda backend that works for basic
functionality but doesn't support all the bells and whistles (like
account balances in the account tree) in the hopes of getting more of
us working on making it feature-complete relative to the xml
backend. It seems to me that the sorts of far-reaching changes
required shouldn't be done in a separate branch at that point, but I
don't know. 

just my meager .02

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/afb8bd34/attachment.bin 


More information about the gnucash-devel mailing list