Dirty entity identification.

Neil Williams linux at codehelp.co.uk
Fri Jul 22 04:10:13 EDT 2005


On Friday 22 July 2005 1:01 am, you wrote:
> You clearly haven't understood my statements.  I don't want to have to
> run the list of collections each time I ask if the book is dirty.
> That's too much work.

It's not. At no time do you iterate through the entire collections to do this. 
The code does iterate over the tiny number of primary collections but that 
takes no time at all. It takes longer to call the function itself than it 
does to check 12 or so boolean pointers, especially once that function is in 
a shared library.

> I want to short circuit that entire process by 
> checking *one* *flag* in the book.  Not the collections.  The book.  I
> would like the code that marks the collection as dirty to also mark the
> book as dirty.  None of the code I'm working on cares what has changed,
> only that something has.

The only problem with that is that the dirty flag in the book is not exposed 
directly (or won't be once I've cleaned up the private header file issue). 
You need to call a function via the API and that function will check the 
collections. It really is no overhead.

> Yes, thanks.  I've seen that code.  (Insert wry face here.)  Nowhere
> have you stated that setting the dirty flag on a collection will also
> set book->inst.dirty.  In fact, you've gone through some serious
> contortions to avoid saying it.

Because, as yet, it doesn't but neither does that matter.
:-)

The book reports as dirty if the collections are dirty. As there are so few 
collections, it makes more sense to check each collection when asked rather 
than continuously set the book dirty flag every time another collection has 
changed.

It's retrospective, not prospective. I see no need to check or set the book 
dirty flag every single time a single entity is changed, again and again and 
again throughout the entire session. Propagating the flag to the collection 
is sufficient.

The API is: If the book detects that a collection is dirty, the book reports 
itself as dirty.

Reading the dirty flag directly will not be possible (as this would expose the 
entire private QofBook struct in the API).

It shouldn't have been exposed and UI source files should not be including 
qofbook-p.h, it will not be available when using QOF as a library.

> O.K.  Lets try another approach.  The following is what I want.  Tell me
> why you can't implement it.
>
> gboolean
> qof_book_is_dirty (QofBook *book)
> {
> 	return book->inst.dirty;
> }

That's currently called qof_book_not_saved().

> guint
> qof_book_get_dirty_time (QofBook *book)
> {
> 	return book->dirty_time;
> }

I'll consider that.

> void
> qof_book_set_dirty (QofBook *book)
> {
> 	book->inst.dirty = TRUE;
> 	if (book->dirty_time == 0)
> 		book->dirty_time = time();
> }

But it's pointless even checking this EVERY single time an entity changes. 
Nobody wants that information, all we want is to detect the FIRST change.

This function would get called every time qof_instance_set_dirty() is called 
and that's just overkill.

Instead of calling the collections ONCE each, you want the instance to call 
the book EVERY single time it changes! Instead of 12 or so calls, you are 
recommending tens of thousands when only ONE is necessary.

That's like the foot soldier telling the major-general every time he starts to 
walk!
:-)

Instances get dirty, it's their job, it's what they do. Books don't need to 
know every single time. Once is perfectly adequate.

There could be tens of thousands of calls that set an instance dirty during a 
user session - many instances are set dirty repeatedly already. The book 
simply doesn't need to be told, it can ask when it needs the information 
(which is far less often than it may appear).

Better, IMHO, to check the collections and cache the value - after all it is 
the UI that controls WHEN the data is saved and how. Until the UI issues a 
save command, the first dirty flag is the same as the last, there's no point 
calling set() every single time.

There's also no point in asking the book if it is dirty once you've got the 
answer YES. It will stay dirty until the UI issues the qof_session_save(). 
The book itself has no control over the save operations - it cannot clear 
it's own flag and it cannot force a save. This function shouldn't need to be 
called every few seconds or at every window paint. Cache it and wait for a 
Save.

There's no point asking the book if it is dirty again and again and again. 
It's told you once, that's all it can do.

Therefore, qof_book_not_saved needs to be called far fewer times than you seem 
to imagine.

> void
> qof_book_set_clean (QofBook *book)
> {
> 	book->inst.dirty = FALSE;
> 	book->dirty_time = 0;
> }

At no time can the set_clean functions be public, these are reserved for the 
backends. There is no situation where the UI can be allowed to set the book 
to clean without going through a Save.

> It totally baffles me why this has taken more than three email messages.
> Do you not have a back pointer from the collection to the book?  That
> seems like a *HUGE* oversight if that's the problem.

Yes, each collection has a pointer to it's book. I just don't see the need to 
pass that flag back every single time an entity is ever changed. When you 
need to know that information (which is after the first change ONLY), the 
collections can be checked. I believe it is more efficient for the UI to 
cache this value until such time as the UI issues a Save command when it is 
rechecked.

We should be providing information when it is requested, not setting it 
repeatedly when nobody cares anymore.

-- 

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


More information about the gnucash-devel mailing list