On Wednesday 20 July 2005 9:46 pm, Chris Shoemaker wrote: > ISTM you have the two extreme cases: XML only needs to track dirtiness > at the file (book?) level
But the book looks to it's collections to determine if it is dirty. > , since it has to rewrite everything anyway. That only considers the current GnuCash XML backend - QSF can write out and import anything you provide. > SQL doesn't need to track dirtiness at all because commits are > immediate. Yes. > So what does tracking Collection-level dirtiness buy us? Time! (When asking the book if it is dirty). Plus the ability to use QSF which can export only a single collection of entities. With so few object types relative to instances, there's no advantage in setting the flag in the book every time an instance is edited. Just set it in the collection and the book will check the limited number of collections when asked. > ISTM, if there's some middle-ground where dirtiness *does* need to be > tracked on each instance because commits are not immediate, You'd need some form of incremental storage. Not sure what you are getting at. > and yet > commits don't have to write ALL the data, then you'd want to find the > dirtiness by tree search, not by linear search for each object type. BTW, what does ISTM mean? I Seem To Remember, I know, ISTM? > > -chris -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgp07i7rQqcFJ.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
