[Gnucash-changes] Spruce up the delete window dialog to make it more HIG compliant.

[Chris Shoemaker]

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
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel