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/
pgpiQ6SbuSLXx.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
