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

[Chris Shoemaker]

On Wed, Jul 20, 2005 at 09:05:21PM +0100, Neil Williams wrote:
> On Wednesday 20 July 2005 8:35 pm, Chris Shoemaker wrote:
> > > 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."
> 
> Yes, but not in the way you describe below!
> :-))
> 
> > 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.
> 
> I think that can be handled through the existing event handler interface, 
> without more confusion about what is meant by dirty.
> 
> Derek: Did you mean that the event would make a parent instance dirty (i.e. 
> Trans -> Account) or just that it would trigger different events in the GUI 
> according to whether it was a Trans or an Account?
> 
> > > 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 SQL backend is the only one that can handle such differentiation in 
> storage and that can handle such things using the last_update mechanism. I 
> don't see the need for a second dirty mechanism.
> 
> last_update was (AFAICT) designed to cover exactly your example.

So you're saying that somehow, I don't have to search through 100000
Splits and I don't have to commit every Split, even though I'm only
recording dirtiness on the Collection?  and this is unique to the SQL
backend?  Is that because all edits are committed immediately and
dirtiness isn't even relevant?

-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