Dirty entity identification.

[Neil Williams]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050722/076c5858/attachment.bin