help in understanding GNUCash architecture

[John Ralls]

> On Mar 22, 2017, at 8:05 AM, stanislav at taktaev.com wrote:
> 
> Dear Jonh!
> I saw git history on GNUCash and understood that you made a lot of commits to different modules.  
> I have the idea to connect blockchain to GNUCash as database. It seems to me very useful because, when successful,  GNUCash become first worldwide distributed accounting system.
> Can you help me to understand, how GNUcash DB engine designed and works "under the hood" and how do design and connect new DB engine?
> 
> If you are busy, could you recommend someone who can advise me about this?

Please do not contact developers directly. We have mailing lists for that: 
https://lists.gnucash.org/mailman/listinfo/gnucash-devel <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
https://lists.gnucash.org/mailman/listinfo/gnucash-user <https://lists.gnucash.org/mailman/listinfo/gnucash-user>

Your question is a development one, so I'm copying gnucash-devel in this reply. You should subscribe to that list and be sure to copy the list on all of your future replies.

GnuCash at present uses the backend as a plain datastore: If the user has selected the XML backend, the file is loaded into memory at start up or when the user opens a new file, optionally saved (manually or automatically) periodically during the session, and saved again when the user closes GnuCash or opens a different file.

The SQL backend is similar in that the database is loaded in its entirety when opening a new session, but different in that any change to an object is immediately written back to the database.

Having to have everything in memory creates a bunch of limitations, especially with regards to multiple users accessing the data at once, so we have a long-term project to recast GnuCash as a normal SQL database application that loads only the data it immediately needs and can lock records for editing. Thanks to some poor design decisions
in the past and our decision to concurrently redo much of GnuCash's internals in C++ (from incorrectly done GObject code), this is a many-year project.

You're not the first to suggest a block-chain based backend, but so far no one has come up with a significant advantage or a reasonable plan for implementation. I'm looking forward to seeing what you propose.

Regards,
John Ralls