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. 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. Can anyone think of a better approach? How about collections? Should they be persisited, or are they all run-time caches? Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
