AUDIT: r23164 - gnucash/trunk/src/engine - Bug 684670 - Interest amount calculation is wrong in Sqllite3 format

[John Ralls]

On Sep 17, 2013, at 12:14 AM, Wm Tarr <wm.tarr at gmail.com> wrote:

> On 13/09/2013 15:11, Derek Atkins wrote:
>> John Ralls <jralls at code.gnucash.org> writes:
>> 
>>> Yet another corner where forgetting to run a edit-commit cycle when
>>> changing state breaks database save.
>> And people wonder why I still recommend against using the SQL backend
>> for real data..  ;)
>> 
>> -derek
>> 
> Would someone be kind enough to point out the beginning of this thread?  TIA

The beginning of this thread is a change-mail from gnucash-patches or gnucash-changes. You can subscribe to one of those lists if you want to track all of the changes committed to the repository.

Since you're not already subscribed--otherwise you'd know--you can see the change in question at [1].
> 
> There is no reason why the SQL back-end should be failing other than someone didn't code something correctly, surely?


Well, yes. That's what bugs are all about, right?

The fundamental problem with the SQL backend is that while Gnucash has a facility for marking changed data structures as needing to be saved ("dirty"), the XML backend just uses it to light up the save button in the toolbar. An actual save saves *all* state to a new file, so as long as *something* gets marked dirty, everything's fine. The SQL backend doesn't work that way, of course: That's not how you use databases. Only objects marked dirty get updated in the database. Over the years, we were not as disciplined as we should have been about making sure that every object got marked dirty when changing its state. Some of those problems have been noticed and reported like the bug [2] I fixed with r23164; others haven't. Fixing that is my project for the next few weeks. I'd like to have the SQL backend working fully for 2.6.0.

Regards,
John Ralls

[1] http://svn.gnucash.org/trac/changeset/23164
[2] https://bugzilla.gnome.org/show_bug.cgi?id=684670