SQL BackEnd Clarification

[John Ralls]

On Dec 2, 2013, at 8:14 AM, Russell Mercer <rmercer206 at gmail.com> wrote:

> Derek,
> 
> To be clear then, what you are saying is that even though the SQL backends
> like SQLite, MySQL or PostgreSQL have been offered as equal storage options
> to the basic .xml file, the reality is that a potential for data loss
> exists for them that does not exist for the .xml storage?
> 
> It seems to me that if the potential for data loss exists by using the
> alternate storage formats, this should be clearly noted in the
> documentation.  I would hate to be the new user that starts with the
> software, enters a large amount of data into an sqlite format, for example,
> and then loses data, as you say, because they happen to hit one of the
> bugs.
> 
> I completely understand that this is an all volunteer operation and that
> the ability to address bugs is limited by the time that you and the other
> programmers have to devote to the product.  Don't mistake this for not
> being appreciative of that, because the work you have done is tremendous
> and the product is fantastic.  At its most basic, it would seem that being
> able to enter data and have it be saved in a regular manner is of extremely
> high importance, to the extent of being expected functionality.  If using
> an SQL backend means that there are cases where saving does not always
> occur and data loss could happen, that should be clearly noted that these
> are not stable formats and the only recommended storage file type for
> consistent saves is .xml.
> 
> I hope I'm not taking this out of context and blowing it up into more than
> it is.  What may seem like something small to you from a developer
> standpoint looms large to me when I hear that my data may not all be saved
> in an SQL backend, when I think it is being saved.

We've been pretty clear throughout the 2.4 life cycle that the SQL backend has issues and should only be used with great care and vigilance. Several bugs have been reported over the two years since 2.4's initial release regarding incorrect storage in some corner of Gnucash, and I fixed the last one of them last week. 

OTOH, I've also been using the SQL backend for my personal accounts since 2.4 released and I haven't had any problems, but that's because I don't use any of the features that had problems. After all, I'd fixed all of the features I use during the 2.3 cycle. ;-).  But I don't use the business features, the mortgage calculator, or budgets. There are probably other features that I don't even know about and haven't tested. Other people do, and in some cases have submitted bugs. As I said, I've fixed all of them for 2.5.x, so I can confidently say that 2.6 will be a lot safer to use with the SQL backend than 2.4 is. That said, there still isn't comprehensive test coverage and GnuCash's code base is quite complex so that it's impossible to be sure that all execution paths call the write code upon which the SQL backend depends. Until we have that test coverage or have properly enforced the privacy of persistent objects (or better yet, both) we can't be absolutely certain that all uses of the SQL backend are as safe as the XML backend. 

Regards,
John Ralls