Dirty entity identification.

Neil Williams linux at codehelp.co.uk
Fri Jul 22 15:33:51 EDT 2005

On Friday 22 July 2005 5:14 pm, David Hampton wrote:
> Really?  My way.  Load the function argument (1) and function address
> (2), call the is_dirty subroutine (1), load the structure offset (1),
> read the value (1), return (1).  Depeneding on whether or not a stack
> frame is needed add another 3 instructions.  7 to 10 total instructions.

You're neglecting all the extra calls back to the book during editing when it 
is already dirty. Why bother? The dirty flag in the book is there for 
non-Collection data that may be added (using qof_book_set_data). When calling 
qof_book_not_saved() that's checked along with the collections. I really 
can't see any point in changing that. What we have will meet your needs, 
there's no need to add thousands of extra calls, all identical to the first.

> > You need to call a function via the API and that function will check the
> > collections. It really is no overhead.
> Its anywhere from the equivalent of what I'm proposing, to seven times
> more work.

I disagree, having the collections call the book at every single edit is 
pointless and wasteful. Just editing one transaction could fire off SIX of 
these edit calls - what's the point? It's bad enough setting this in the 
collection every time, that has to be done. The book does NOT need to be told 
every single time. It's a step too far for every single edit.

When the book is asked, the book finds out and passes back the answer. Far 

I'd rather have the current routine that is called infrequently than a call 
that is called for absolutely no reason at least once every time anything in 
the application is edited.

> This *is* detecting the first change.

And then it passes the call back for the next change and the one after that ad 

This is getting us nowhere and just delaying the rest of the work. Can't we 
agree to disagree on this?


Neil Williams

-------------- 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/7add30f9/attachment.bin

More information about the gnucash-devel mailing list