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 > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
