Dirty entity identification.
linux at codehelp.co.uk
Fri Jul 22 15:57:05 EDT 2005
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050722/076c5858/attachment.bin
More information about the gnucash-devel