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

Neil Williams linux at codehelp.co.uk
Wed Jul 20 16:05:21 EDT 2005


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.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050720/32afb9b5/attachment.bin


More information about the gnucash-devel mailing list