Using an externally hosted postGreSQL as a gnu cash backend?

[Michael Wagner]

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