Ensuring that all state-changes are written out to SQL
janssens-geert at telenet.be
Mon Sep 30 11:11:19 EDT 2013
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 ?
> 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