Dirty entity identification.
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
> > to book, too.
> > 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?
> 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
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel