r19673 - gnucash/trunk/src/backend/sql - Bug 632166: Notify user when something goes wrong with a transaction save.

John Ralls jralls at ceridwen.us
Tue Oct 19 14:15:17 EDT 2010

On Oct 19, 2010, at 7:59 AM, Geert Janssens wrote:

> On Tuesday 19 October 2010, John Ralls wrote:
>> On Oct 19, 2010, at 2:22 AM, Geert Janssens wrote:
>>> On Monday 18 October 2010, John Ralls wrote:
>>>> Author: jralls
>>>> Date: 2010-10-18 17:56:05 -0400 (Mon, 18 Oct 2010)
>>>> New Revision: 19673
>>>> Trac: http://svn.gnucash.org/trac/changeset/19673
>>>> Modified:
>>>>  gnucash/trunk/src/backend/sql/Makefile.am
>>>>  gnucash/trunk/src/backend/sql/gnc-transaction-sql.c
>>>> Log:
>>>> Bug 632166: Notify user when something goes wrong with a transaction
>>>> save.
>>>> _______________________________________________
>>>> gnucash-patches mailing list
>>>> gnucash-patches at gnucash.org
>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-patches
>>> John,
>>> This change is definitely an improvement to the silent data loss issue we
>>> had.
>>> I see that your commit now introduces a gtk dependency in the sql backend
>>> while it was strictly gui independent before. I have postponed fixing bug
>>> 630770 [1] because I wanted to avoid adding gui code to the backend. My
>>> main reason for keeping the databackends free of gui code is that other
>>> programs may use this code, programs that aren't necessarily using gtk.
>>> The first example is CuteCash, a second example are the python bindings.
>>> I'm not sure what the best course of action is here. Silent data loss is
>>> a severe flaw, so perhaps it's better to have the introduction of a gtk
>>> dependency now so we can continue, and clean it up properly in the 2.5
>>> development cycle. Or perhaps the majority of the devs doesn't consider
>>> this an issue in which case nothing has to be done.
>>> Cleaning it up now would probably be challenging or too intrusive. When I
>>> was investigating a way to fix bug 630770 I came to the conclusion that
>>> backend errors are not reported back all the way into the GUI code. There
>>> were several in between layers that had to be altered for that.
>>> If the choice is to clean it up later, we best keep a bug report open for
>>> this.
>>> What do others think of this ?
>> Geert,
>> You raise a very valid point. Mixing the gui into the  isn't a good
>> long-term approach, especially if we're going to dump Gtk anyway. On the
>> other hand, the backend already uses gopbject pretty extensively and that
>> is all going to have to be redone in C++ (or come other OO language, but
>> C++ will be easiest) if we're going to get away from Gtk.
> I'm not sure if all has to be redone in C++ or another OO language. At least 
> not necessarily in the same refactoring phase. My understanding was that even 
> Cutecash would initially only focus on an enhanced gui on top of the current 
> qof/gobject based engine.
>> We need a global error handling class (it can be grafted onto qoflog) with
>> a single-point dependency to a message box facility in gnome-utils.
> Agreed.

Well, it appears we've already got one: qof_backend_set_error(), in src/libqof/qof/qofinstance.h.
It handily solves both 630770 and 632166. It could use enhancing with amplifying information (like what transaction is borked), but it will do for now without breaking anything. 

John Ralls

More information about the gnucash-devel mailing list