[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