On Aug 12, 2011, at 1:38 AM, Christian Stimming wrote: > Am Donnerstag, 11. August 2011 schrieb John Ralls: >> On Aug 11, 2011, at 12:28 PM, John Ralls wrote: >>> Muslim discovered a couple of functions in QofSession.c, >>> qof_instance_copy_coll_r and qof_instance_copy_one_r, along with a >>> companion test src/engine/test/test-recursive.c which seems intended to >>> support a hierarchy of books. Given the way we treat books, this seems >>> to me to be a seriously dumb idea. It seems to have been added in >>> mid-2005 by Neil Williams as part of a conversion to Gnome 2. Does >>> anyone recall the rationale behind it? Is there any reason not to remove >>> it as useless cruft? >> >> Another batch of unused functions from qofsession.c, called only by >> python_bindings/gnucash_core.c: qof_instance_copy_to_session, >> qof_instance_copy_list, qof_instance_copy_coll >> >> These (and the other two mentioned earlier) are implemented in part by the >> following static functions (which aren't used for anything else, as can be >> seen from the list of callers): >> >> qof_book_set_partial qof_session_update_reference_list, >> qof_instance_copy_to_session, qof_instance_copy_list, >> qof_instance_copy_coll >> qof_session_update_reference_list col_ref_cb, qof_instance_foreach_copy >> qof_instance_param_cb qof_instance_list_foreach, >> qof_instance_copy_to_session, qof_instance_copy_coll >> col_ref_cb qof_instance_foreach_copy >> qof_instance_foreach_copy qof_instance_list_foreach, >> qof_instance_coll_copy, qof_instance_copy_to_session >> qof_instance_guid_match qof_instance_list_foreach, >> qof_instance_copy_to_session >> qof_instance_list_foreach qof_instance_copy_list >> qof_instance_coll_foreach qof_instance_copy_coll >> qof_instance_coll_copy qof_instance_copy_coll >> recurse_collection_cb recurse_ent_cb >> recurse_ent_cb qof_instance_copy_coll_r >> >> Unless someone objects convincingly, the whole steaming pile is coming out. > > I agree those should be moved out. The reasons are still the same as earlier > this year: As those are not (yet) in use, they are most likely wrong anyway > and need to be re-implemented when actually needed anyway. >
I think in this case we don't want them ever to be used. Having a hierarchy of books would require a complete redesign of Gnucash's basic architecture, where a "book" is the top-level container for all of the accounts. Along a similar vein, there's src/engine/period.[ch] and the "gemini" structure which depends upon it. The idea there appears to be that when one closes the books (in the accounting sense) at the end of a period, the book (in the Gnucash sense) also gets closed out and a new one is cloned from the old one. Users periodically ask for that and we tell them that that's not something we want to do, because the history gets broken up into several files. (It would work better with a proper DB backend like DBI, where the "new" book just means a new GUID on records and searches can span multiple books. For that matter, there's no reason an XML file couldn't also have several QofBooks in it. This could be made to work well with XQuery -- or even just XPath -- integrated into the XML backend.) If we really don't want to do that, we should rip out all of that code so that it doesn't have to be included in the "transactional" redesign. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
