cmd line: import of transactions and invoice data

John Ralls jralls at
Wed Jan 1 12:25:30 EST 2014

On Jan 1, 2014, at 2:04 AM, Emmanuel Florent <emmanuel.florent at> wrote:

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

What problems are you trying to solve? You've jumped into Jannick's thread about importing,
but none of this seems germane.

Why would you want to save GC's xml into a db? What would you do with it then?

Many people already keep their GC files in Dropbox or similar for access from 
multiple machines and or for offsite backup. Works fine.

Gnucash *probably* writes things to the XML file in the same order that they were read
in just because we use linked lists for just about everything internally, but there's
no guarantee of that and it might well create excessive churn in a version control
system. But we already rename the loaded XML file and write out a new one, so you can
easily back up a bit.

NoSQL isn't a good fit for accounting data. Neither is XML, actually. Relational
databases were invented specifically for accounting programs. GnuCash already has
a SQL backend that can communicate with MySQL and Postgresql servers and we intend to
make GnuCash a proper RDB/SQL application with all queries to the RDB instead of
sucking everything into memory as we do now. The XML backend will convert to creating
an in-memory SQLite3 RDB at startup which gets written back out to XML for saves.

If you want to develop something, join the team and work on that. We'll be working in C++
for new code, but there's plenty of work to do in C as well.

John Ralls

More information about the gnucash-devel mailing list