Ensuring that all state-changes are written out to SQL

[Geert Janssens]

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.

Geert