Dirty entity identification.

Chris Shoemaker c.shoemaker at cox.net
Fri Jul 22 10:25:47 EDT 2005 

On Fri, Jul 22, 2005 at 10:13:55AM +0100, Neil Williams wrote:
> 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.

Nope.  Accounts contain a list of Splits.  This is an essential part
of an Account, and *something* needs to know about it and take
advantage of it.  Other than the GUI.


> 
> > > 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.

You could say the same thing about the Collection.  But actually, there is just as much reason in both cases.

> 
> 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 missed the point here.  Forget about the engine.  This was a
*mathematical* statement about searches.  Having information about the
presence (or absence) of what you're searching for in a subset of all
the places you could look at a cost less than the cost of actually
looking in all those places makes your search cheaper.  This has
nothing to do with everything that the "engine cannot know."

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

No.  I made no assertion about *who* can follow that path.  But the
path does and must exist and we use it already to accomplish most of
the financial operations.

> 
> > > 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.

You're really hung up on this.  Transactions and Accounts aren't
directly related.  Neither are Budgets and Vendors.  So what?

-chris

> 
> 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/
> 



> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

More information about the gnucash-devel mailing list