Ensuring that all state-changes are written out to SQL
jralls at ceridwen.us
Mon Sep 30 12:38:07 EDT 2013
On Sep 30, 2013, at 8:11 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
> On Sunday 29 September 2013 09:44:39 John Ralls wrote:
> > A few days ago I announced my intention to fix this for 2.6. I've
> > since been trying to think of a practical way to get there.
> > My first thought was to write tests that trap every state change of a
> > database class object and check that it's marked dirty. While given
> > infinite time that's undoubtedly the best approach, I'm not likely to
> > be able to get 100% coverage written in the 3 months remaining to our
> > scheduled 2.6 release. I need a compile-time solution that requires
> > only a month's worth of coding.
> > The approach that comes to mind is to lock down the persisted classes:
> > All setting and getting, including of KVP parameters, would be via
> > g_object_set (), which can easily be wrapped in a function
> > (gnc_object_set()) that checks that there's an edit in progress and
> > marks the object dirty so that it will get written out when the edit
> > is committed. All of the direct setting functions will be static in
> > the class implementation.
> Looks ok to me. I suppose that next to gnc_object_set, the convenience api's remain as well ? So that you could still call say xaccTransSetDescription () which internally will call gnc_object_set on the description property ?
I wasn't planning to go that way, but it would save tracking down and changing all of the calls, so I think I will do it.
> > There's one bit that I'm unsure about: QofCollections, which have
> > "qof_alt_dirty_mode" which I think is supposed to delay marking them
> > dirty, but in fact just doesn't. QofBook's use of QofCollection is
> > to map GUIDs to pointers, and so shouldn't be persisted at all (they
> > are, though). I haven't examined the rest, but I see a lot of places
> > where QofCollections are checked for being dirty, which in the
> > presence of qof_alt_dirty_mode (which is set to TRUE at program
> > startup, in gnc_engine_init_part_1()) is never true.
> That's too deep into qof for my knowledge, so I'll leave it to others to comment on this.
More information about the gnucash-devel