Dirty entity identification.

[Neil Williams]

On Friday 22 July 2005 2:54 am, Chris Shoemaker wrote:
> > > How do we dicover that it contains a dirty split?  Either we have to
> > > search through *every* split in the Collection, seeing if it's in our
> > > account and is dirty, OR, we just check our Account's "contains
> > > something dirty" flag.  Big difference.
> >
> > This clearly illustrates the nature of the search: It is an OBJECT issue
> > and it needs to be done in the objects.
>
> Ok.  as opposed to .... where?

The backend, the book, the engine or the session, none of which understand 
anything about what you are asking.

As the tree only exists, if at all, in the UI then only the UI can handle it. 

> > So the Account can only iterate over all it's splits and the Trans can
> > only iterate over all it's splits. Neither can identify a single split
> > without iteration. The hierarchy is not symmetrical neither is does it
> > accord with the tree model.
>
> I'm not sure it's all that complicated.  I think split cascades to
> account, 

Yes, but only in the OBJECT - this has nothing to do with the engine, backend, 
book or session.

> account cascades to  

QofCollection *coll = qof_book_get_collection(book, GNC_ID_ACCOUNT);

> and transactions can just cascade 

to their collection, (QofCollection*) ... (book, GNC_ID_TRANS)

Note, singular. One object, one collection. Without a collection, there is no 
object.

> to book, too.

Nope.

> With a few other things cascading up to book, I think 
> David would have what he wants.

There is no need for the book to be continuously told (or asked) the same 
thing, thousands upon thousands of times.

When it is asked, it finds out.

Once it has found out, the result can be cached until the UI asks for a Save. 
The engine has no need to make any further information available, the answer 
was given and nothing will change until the process that ASKED for the 
information asks for a Save operation.

Just because the UI asks twenty thousand times, doesn't mean the book will 
ever give a different answer, once it is dirty, it stays dirty until the 
*user* decides otherwise.

> > You've also switched to only knowing IF there is a dirty split in the
> > account, not positively identifying WHICH split is dirty.
>
> These are quite related.  Knowing the an account does or doesn't
> contain a dirty split makes it much easier to find the dirty splits.

Unfortunately not. The engine cannot know that a dirty "account" (whatever 
that is) means a dirty Split (whatever that might be) exists somewhere. There 
is no relationship. The engine only knows that this instance is dirty, that 
collection is dirty and therefore the book is dirty. End.

You continue to assert that the engine can follow a path that simply does not 
exist. There is no tree!

> > The only reason for a tree search is to find WHICH entity is dirty.
> > Setting a single gboolean flag is trivial.
>
> That's right, and that flag makes the tree search possible.

It does not and cannot because no tree exists to search!!

Seeing as you've quoted this, I'll enhance it a bit:

NOTE: All paths indicated here are UNIDIRECTIONAL, from top to bottom. There 
is *no* reverse call or symmetry, implied or otherwise.

> > Try this in ASCII / Fixed font display:
> >
> >                          Split
> >                           |   |
> > 		Trans------    ------Account
> >              |                               |
> > 	    GList of Splits      GList of Splits
> > 	     in this Trans       in this Account
> >

Note the disconnect between Trans and Account.

Once you've obtained a Trans from the Split, you cannot ask the Trans which 
Split it came from, it doesn't know! You have to store that information from 
when you first found the Split. Same with Account. Each knows their list of 
Splits but it cannot tell you WHICH in that list is the one you want.

So you know an Account is dirty, big deal. There is no way the engine can tell 
you WHICH split in that account is dirty without iteration. To the engine, 
it's just an object and a set of parameters.

> >
> > That's how the source code implements the "tree".
> > (events notwithstanding.)

Any communication between an Account and a Trans MUST occur via the relevant 
Split and that requires iteration, at the very least a qof_entity_lookup from 
the GUID and GNC_ID_SPLIT. That's a GHashTable lookup, it's highly optimised 
but the hashtable still needs to be initialised with iteration. Yet even this 
lookup has little to do with the "tree".

Please forget the entire idea of a "tree search" - there is no tree, there 
never has been.

I really wish I had said that the first time you mentioned this craziness.

Another note to self:
Listen to Derek, he's been here before and if he says there's no tree, there 
simply is no tree!!!
:-)


-- 

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/09274e5d/attachment-0001.bin