On Sep 17, 2013, at 12:14 AM, Wm Tarr <[email protected]> wrote:
> On 13/09/2013 15:11, Derek Atkins wrote:
>> John Ralls <[email protected]> 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
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
