Having experienced all of the benefits...

Colin Law clanlaw at gmail.com
Mon Sep 15 11:56:40 EDT 2014


On 15 September 2014 14:26, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
>
> That's indeed one way to go and close to what I think a gnucash app should
> do.
>
> It shifts the focus to next, closely related issue: GnuCash was not designed
> as a database application. I consciously left out such detail in my original
> reply, however since you brought it up... :)
>
> I am sure I'm repeating what has been said in the past. GnuCash can
> currently use a database as an immediate write-back store.
>
> This feature was written with reducing the risk of data loss in mind. Data
> loss that could occur with the xml file if you didn't save regularly enough
> and the system would crash. Using a database in current comes with a small
> additional side benefit that you gain some time when closing gnucash. You
> don't need to save anymore.
>
> That's unfortunately all the current database implementation provides as
> "features". You can't access the database simultaneously because the master
> data is still kept in memory, not in the database. Also any change behind
> gnucash' own interface will not be seen by gnucash and potentially
> overwritten by an action inside gnucash.
>

That is why I said in the short term it would be necessary to have a
lock to prevent http access whilst GC was open, until the work you
describe has been completed.  Perhaps short term is over optimistic :)

>
> Going further still: the database does keep referential integrity, but not
> all business restrictions are encoded in the database structure. I even
> think they can't be. So updating the database outside of gnucash comes with
> the real risk of invalidating your financial data. Things like transactions
> that no longer balance, splits that don't belong to any transaction,
> invoices and payments that no longer match, things like that.
>
> And yes, you can argue all these restrictions can be implemented in your
> json api. Totally agreed, you can. But then you are effectively rewriting
> the gnucash engine as a separate project, because that is what the gnucash
> business engine was written to do. It will take a considerate amount of time
> and you will end up with two codebases to maintain, fix bugs in and
> implement new features in. That is not a wise thing to do in my humble
> opinion.

I entirely agree that would not be the right way to go.  I had assumed
that the json i/f would be an interface into the GC codebase, not into
separate code.  So there would only be one set of code managing the
database.

>
> All of the requests about multi-user database access, web interface, mobile
> versions and such have been heard by the developers. It's these requests
> that have pushed the rewrite of the gnucash core that is currently ongoing.
> Such rewrite takes time. Available time is limited. So things go slow
> unfortunately. But the focus to enable these things is there.

I was not saying that the current approach is not correct, just that
to provide GC on mobile devices is not a port of existing GC code.
There is work to do, on the mobile device and extensions to the GC
code but it is not a port.

Is part of the current work to provide a stable interface into the db
engine (by stable I mean one that is not liable to change without good
reason)?  One that the http i/f could drive the db through.

Colin


More information about the gnucash-user mailing list