> On Jan 8, 2015, at 8:50 AM, stuartb <[email protected]> wrote: > > Hi John > > Thanks for the comprehensive reply. Sorry for the confusion, I am aware of > GNU - bad choice of abbreviation. > > Regarding GPL, no problem, we currently work with other open source projects > for the same reasons (Alfresco being a good example). Rather than re-create > every module from scratch we prefer to adopt a middleware approach and > bridge existing systems together. We can then query those systems via > API's or the database directly to present this data to the user in various > ways. Our own product follows an SOA approach which allows us to bolt on > different services depending on our clients needs. This is what brings us > to gnucash. > > Just to confirm; the method you proposed was our first idea, maintaining our > existing database structure but constructing a synchronization module to > keep the two datasets in sync. This would keep the projects completely > separate and allow us to maintain the use of triggers and database > transactions. > > On reflection, the loading of the dataset may not be such an issue if > gnucash was viewed as a read only reporting module (multiple users could > also synchronize the master dataset). Our larger clients already run > existing server-side accounting systems which we feed data to using web > services - the gnucash connector would allow us to provide an alternative to > the smaller MGAs which we deal with, who already use Quickbooks and Sage and > are looking for alternatives. > > Can I confirm; if a record is modified in the database - are you updating > the entire mysql dataset, or just pushing the changes ? >
I’ll answer the direct question first: GnuCash loads the database at startup and writes back every commit immediately. It does not requery the database unless it’s closed and re-opened. That means that a running GnuCash won’t see — and might overwrite — any changes made in the database. For that reason there’s a lock table in which GnuCash writes a record at startup and removes at session close (either shutdown or to open a different database); another instance of GnuCash connecting to the database will offer the opportunity to break the lock or to open read-only. That second session would see any changes made by the first one up to the moment it loads the database but nothing after. Since there’s no record locking nothing would prevent the second session from reading in the middle of a commit from the first session and having inconsistent data. Legal: If you use the API of a GPL-licensed work your program becomes bound by the requirements of the GPL. That is intentional, and is why Steve Ballmer famously said that the GPL is a virus. If you keep the bridge as a stand-alone program and release it under the GPL, all is well. Otherwise you’re on thin ice. Have you had anyone look at the GnuCash reporting module? Do you understand that it uses a custom query engine and that all of the reports are hard-coded in Scheme? The existing reports are tailored to personal use and very small businesses, so I would think that your customers, even the small ones, would require a substantial number of new reports, and they’d expect you to write them. Thanks to the fact that you’d be using the GnuCash Scheme API that work would be subject to the GPL. I’d think it would make more sense to just use a SQL report generator. But is it really true that your customers are using QB, sage, or some legacy system just for reporting? Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
