Database PGSQL vs XML from Digest, Vol 157, Issue 20

John Angelico talldad at kepl.com.au
Wed Apr 13 20:14:33 EDT 2016


On 13/04/16 21:44, gnucash-user-request at gnucash.org wrote:
> Message: 5 Date: Tue, 12 Apr 2016 14:27:22 -0400 From: Michael Wagner
> <mikepwagner at mikepwagner.net> To: "gnucash-user at gnucash.org"
> <gnucash-user at gnucash.org> Subject: Re: Using an externally hosted
> postGreSQL as a gnu cash backend? Message-ID:
> <CAPT=E1+YRuErXBohgJ8qRXSVS0YNYz-5cht8Pnf0Y0bG8moz1w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>> >
>> >From: Geert Janssens<geert.gnucash at kobaltwit.be>
>> >To:gnucash-user at gnucash.org
>> >Cc: Plutocrat<plutocrat at gmail.com>
>> >Date: Tue, 12 Apr 2016 12:57:38 +0200
>> >Subject: Re: Using an externally hosted postGreSQL as a gnu cash backend?
>> >On Tuesday 12 April 2016 12:38:33 Plutocrat wrote:
>>> > >Michael Wagner wrote on Tuesday, 12 April, 2016 06:39 AM:
>>>> > > >So gnucash doesn't update the PostGres DB using transaction
>>>> > > >semantics? That's interesting - not doubting you, that just seems
>>>> > > >odd.
>>> > >
>>> > >I think the point he was making was that whatever db backend you use
>>> > >-- XML, sqlite, MySQL, Postgresql -- the way Gnucash works is to read
>>> > >the whole data from the database when it starts up, and only writes
>>> > >it back when you hit save. So as data is not being constantly written
>>> > >to Postgresql, it's not really any more reliable than XML.
>>> > >
>> >No, this is not correct.
>> >
>> >As Colin already writes, the database backend will write each change to
>> >the database
>> >immediately. There is never a need to explicitly save the data (unless you
>> >want to convert it
>> >to another database or xml file).
>> >
> Good, this is what I thought that I had read.
>
>
>> >
>> >The other part in Colin's reply is also correct: gnucash reads the entire
>> >database in memory at
>> >start up and won't read it again afterwards. So if someone alters it
>> >outside of the running
>> >gnucash instance (including from another gnucash instance) these writes
>> >may conflict. In the
>> >best case you have duplicate data, in the worst case you may end up with a
>> >corrupt database.
>> >I'm not sure. As concurrent database writes are not supported the behavior
>> >in such a situation
>> >hasn't been tested.
>> >
> I guess the real solution for this would be to tie gnucash more tightly to
> the DB and rely on the DB's caching algorithms instead of loading the whole
> thing into memory. That should eliminate the stale cache issues.
>
> But I guess that would make the DB/XML file code even more divergent.
>
> Mike
>

Pardon me gentlemen, but are not the two parts of this reply in conflict?

First, "As Colin already writes" the database backend will write each 
change immediately, not at the end of the session.

Then "the other part of Colin's reply is also correct" gnucash reads the 
entire database into memory, and works there until the end of the 
session, leading to the risk of data conflicts and corruption.

Is there already a difference between the file handling under XML vs SQL?

John Angelico
talldad


More information about the gnucash-user mailing list