[Gnucash-changes] Spruce up the delete window dialog to make it
more HIG compliant.
c.shoemaker at cox.net
Wed Jul 20 15:35:20 EDT 2005
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
(*) 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.)
> Neil Williams
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel