On Friday 22 July 2005 6:35 pm, David Hampton wrote: > So why have a book dirty flag at all?
For non-collection data (like the ENTITYREFERENCE hashtable). It's not a big job - frankly. The burden is on the collections, where it should be. > If you have the flag, you must > insure it reflects the state of the system. No, that would only be true IF the flag could be called directly. I'll double check that the flag is good for what (little) it does. The API function reflects the true state of the system, the flag is only one part of that. The private header file changes will ensure that any check on the dirtiness of the book will go via the API: qof_book_not_saved as the flag itself will be out of bounds. > I'm not saying you have to > set the flag every time a change is made, ?? Then why the disagreement about passing the flag back from the collection every time a change is made ?? There is no need to set or check the book flag every time a change is made. Can we agree on that? > just that you ensure that the > flag *always* reflects the state of the underlying collections. It does, absolutely it does - when called via the API. That is precisely what the new function ensures and it is all I have been talking about all along. Honestly, this is driving me nuts because it's an argument about nothing. The API has been fixed to work correctly and you're worried about the internal workings behind that API? Please just use the API, it's fine! Don't use the flag directly, do use qof_book_not_saved and all will be well. Promise. If it goes wrong, THEN you can complain - right now I'm happy, the API is fine and I'm not going to argue this any further. > If it > doesn't do that then the code is broken. It was and I've fixed it! The fix will be in my next commit which is getting larger (and further away) the longer we spend time on these minutiae. Thanks to all here for the heads-up on the qof_instance_set_dirty addition, that's done and all will be well once it's committed. Can I PLEASE get back to my urgent work with QSF and the CLI now? I can't fix that QOF_TYPE_COLLECT problem with so many distracting discussions flying around. > Once you've ensure that the book flag correctly reflects the state of > the collections, what's the point of running the collections in > qok_book_not_saved()? Its redundant work. Because the book flag is only one part of qof_book_not_saved and the flag is NOT in sync with the collections - qof_book_not_saved IS in sync (now) with ALL parts of the book, so that is the API. Please use it. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpm21omR9pxJ.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
