sql not as stable as xml, but stable enough (2.4.0, what's left to do)

Christian Stimming stimming at tuhh.de
Mon Nov 15 14:53:43 EST 2010


Am Montag, 15. November 2010 schrieb John Ralls:
> On Nov 15, 2010, at 6:12 AM, Geert Janssens wrote:
> > The previous thread on getting 2.4 released initiated by John turned into
> > a discussion whether to disable the SQL backend or not due to stability
> > issues. I haven't closely watched the recent commits in that area, but I
> > wonder if this situation has changed now. Is the sql backend now
> > considered ready for public release ? Or do we still have to implement
> > the suggestion of an "Export to sql" menu next to the Save As menu [1]
> > which several developers liked ?

In my opinion the backend did improve on some parts, but some unknowns might 
remain. However, all reports about missing data have now been dealt with in 
detail, which wasn't the case 2 months ago, and also the data locking is 
implemented to avoid unexpected multi-user collisions. So IMHO even though 
there remain some unknowns I think it is stable enough to call this, well, 
stable.

> At this point, I think the sql backend is at least as  reliable as the xml
> backend -- perhaps more so.

I do not agree with this statement. The sql backend is reliable enough to be 
used by a wide audience, but it is certainly not as reliable as the xml 
backend. The reason is that we know the xml backend for years by now, but 1. 
we do not know the sql backend for a comparable time frame, and 2. the sql 
backend comes not only in one flavour but already three different databases. 
Hence, I expect issues to show up in some databases but not in others, whereas 
in XML we only have one single long-known implementation using libxml2. I 
think it is "enough stable" to release it, but when asked about which one is 
"the most stable", I am very sure this is still only the xml backend.

> There are still plenty of improvements to be
> made, as we're not using all of the facilities available for referential
> integrity or transaction atomicity. There are also still a few open bugs,
> but I think most of them are either obsolete or not related to the
> backend.

With this statement I do agree. There's still improvements to do. But the 
current state is now sufficient for a stable release. Thanks everyone!

Regards,

Christian


More information about the gnucash-devel mailing list