Loading whole db at startup (was Re: String lengths in the SQL backend)
plongstaff at rogers.com
Mon Nov 17 09:53:57 EST 2008
On November 16, 2008 02:01:05 pm Derek Atkins wrote:
> Phil Longstaff <plongstaff at rogers.com> writes:
> >> Wait, the ENTIRE contents are read in? Historically only "necessary
> >> data" was read in. That would be the Accounts and Commodities from
> >> the main CoA. The transactions were all loaded on demand.
> > Yes. I wanted to only read "necessary data". However, my (admittedly
> > incomplete) knowledge of the engine led me to the conclusion that parts
> > of th engine assume that all data is present. I couldn't get the account
> > tree to show correct values, for example, unless all splits for an
> > account were present. I ended up just loading the whole database into
> > memory.
> There should not be any dependence on reading in all the data from the DB.
> The old PG Backend certainly did not, and it worked fine. I think it got
> around it by having checkpoints for things like running account balances,
> so you only need to load "current" transactions, not all of them.
> If you're loading all data all the time then the only benefit to the DB
> backend over the XML backend is save-on-commit.
I've removed gnucash-user because this is getting into development topics.
I thought I was doing what the pg backend was doing, and it wasn't working. I
just looked again and found a difference - the pg backend was setting the
starting balances, and I was setting the ending balances. I'll try again to
not load the transactions and set just the starting balances (balance/cleared
More information about the gnucash-devel