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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
