On Wed, Jul 20, 2005 at 08:19:40PM +0100, Neil Williams wrote: > On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote: > > That reminds me of a question I've had. ISTM, there's some vision of > > "dirtiness" propagating from Instance to Collection. > > There is now, yes. > > > However, I think > > it would make sense if dirtiness propagated up the containment > > hierarchy. E.g. User dirties a Split, which dirties the split's > > Transaction, and Account, which dirties the account's Group, which > > dirties the Book. > > Why such a tortuous path? Split -> Collection -> Book. Checking the book > automatically checks all collections. The Book won't know WHICH split has > been changed so you gain nothing.
Ah, I didn't realize the Collection's dirtiness propagated to the Book. > > With a backend that only stored dirty instances (e.g. by using a local cache > - > SQL), then marking the Trans, Account and Group as dirty is > counter-productive. Those haven't changed, only the Split has changed - it > could make a big difference if the backend is actually a network connection. Maybe there needs to be a distiction between "is dirty itself" and "contains something dirty." I think this was what Derek meant when he was talking about supporting a different event for editing an account than for adding a transaction. One would dirty the Account, the other would only indicate that the Account contained a dirty Transaction. > > These backends could identify which collections are dirty in the book - then > identify which instances are dirty by *only* having to iterate over a those > collections, instead of all collections and thereby all instances. In your > example, the backend would only have to iterate over the Splits, not the > entire book. If you make Group dirty everytime a Split is changed, you lose > all ability to identify *which* instances are actually dirty. > > > Now, a check for the need to save can just check > > the book. > > With the new qof_instance_set_dirty() that will be done in one call. > > > And, the code that commits changes and clears the dirty > > flag could also travserse the tree instead of committing whole > > Collections, or searching in a Collection for the single split that was > > dirtied. > > Ah now that would be slower. No point, as I see it, traversing the entire > tree > - set the collection to clean and all done. Not the entire tree, only the dirty portion. Extreme example: I have 100000 Splits, and edit one of them which happens to be in an Account with only 5 Transactions. A tree search would search 1 book and find 1 dirty*, search 75 Accounts and find 1 dirty*, search 5 Transactions and find 1 dirty*, search 2 splits and find 1 dirty**, and then commit one split. (*) here, I mean "contains something dirty" (**) here, I mean "is itself dirty" > > The QofCollection dirty marker is a single boolean for the entire collection, > it does not require iterating through the collection itself, either to set or > to clear. Then you either need a linear search through 100000 Splits, or just to commit all of them because you only know that the Collection is dirty, not that it contains 1 dirty Split. > > > Incidentally, why does Split not even have a dirty flag? > > I'll be changing that - every object will use qof_collection_is_dirty and > qof_collection_make_clean in their object definitions. > > > What design > > decision governs whether a core engine object should derive from > > Instance or Entity? > > ?? All core structs contain a QofInstance which itself contains a QofEntity. Except for Split, I guess? (I'm actually not looking at the code, so I may be misremembering.) -chris > > -- > > 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
