First of all I wish to the Gnucash community a very good year 2014, could it be just as it ended the previous year: brilliant !
Secondly a big applause for latest release ! So here is my solution, a wrapper: -load xml from "somewhere", -open gnucash, -do work -close gnucash -save Gc xml to db. Somewhere could have be: -a shared network directory, but, if networking problems can be solved, concurrent access problem remain and so it would not be multi-users -a content revision system (think CVS or bzr, ...) but the xml may not be sorted so problems ... -a noslq db where db key should match gnucash's guid, What do you think of that approach, seems not so bad for me to make an initial implementation. PS: Does someone have a real example GC file a little bit big to see how it works in real situation and to help me further dev ? EF 2013/12/31 John Ralls <[email protected]> > > On Dec 31, 2013, at 1:15 PM, Jannick <[email protected]> wrote: > > > John Ralls <jralls <at> ceridwen.us> writes: > > > >> It updates the database after any change to the in-memory data. At > least we > >> think it does, but we don’t yet have complete test coverage to be sure > that > >> we haven’t missed something in our audits. > > > > John, > > > > this is very helpful. > > > > There might be two options: Either the whole db is updated or the changes > > only [Rereading the posting: only changed tables are updated - at most]. > > > > The first one might give rise to an issue when more than one user updates > > the mySQL db at the same time. But good either way I believe if there is > > just one user having access to the mySQL db for a period of time. If the > > whole GC db is - or updated GC tables as a whole are - passed on to > mySQL, > > then the data integrity feature built into GC can be used and need not be > > mirrored in mySQL. Point taken! > > > >>> > >>>> However, GnuCash DOES NOT support you writing to the database behind > it. > >>>> To write the DB you *MUST* use the GnuCash API (in C, Scheme, or > Python). > >>> > >>> This *is* a very good point. For the benefit of my better > understanding: > >>> Given my first guess above is correct, then how does GC work when it > comes > >>> to manually input data or insert it via the AqBanking interface > (HBCI)? What > >>> does it do when information are handed in? > >> > >> It parses the incoming stream and converts it to internal data > structures, > > prompting > >> the user via a dialog box to assign the accounts for each side of the > > transactions, > >> then runs data-integrity routines on each transaction to ensure that the > > transaction > >> balances, creating an imbalance-account-split if it doesn’t. If you’re > > using the SQL > >> backend it updates the various affected tables immediately, otherwise it > > sets the > >> book dirty flag. > > > > Ahh, then the number of updated tables is reduced to the minimum after > the > > GC data-integrity test for the whole in-memory GC db. And - as far as I > > understand - the *whole* updated tables are passed on to mySQL, right? > > > > Just two more FUP questions: > > 1 - What happens if GC comes across a db which fails the data-integrity > > tests (because, e.g., it was updated outside the house)? Is GC able to > cope > > with this still displaying the db to the GC user? > > 2 - I am a little tiny Win7 user (no "building" skills etc). Are there > any > > code pieces to read to understand how the various steps are applied to > > imported transactions? Anything on the GC server? > > No, only the structures “marked dirty” and passed through a commit routine > when changed are updated via SQL. > > GnuCash has a lock record in the database so that only one GnuCash > instance can > open it at a time. It doesn’t use the database-locking facility, so any > non-GnuCash > process could access the database. Since GnuCash only reads the database > once, when > it opens it, this would create obvious problems. > > GnuCash doesn’t have much in the way of data integrity checks; if a > foreign key is > invalid, it will usually just drop the transaction with the bad key, but > in some > circumstances it may crash. The former case would result in silent data > loss, the > second would obviously render the database unusable. Since GnuCash doesn’t > use > any checkpointing features nor does it make any sort of backup with the > SQL backend, > you’d have to rely on having some other sort of database backup that you > could reload > to recover any of the data at all. > > Neither the SQL backend nor the importers are well documented, so unless > you can > read C source code you’re not likely to be able to replicate the function > of GnuCash’s > internals. > > Regards, > John Ralls > > > _______________________________________________ > gnucash-devel mailing list > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
