On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote: > That reminds me of a question I've had. ISTM, there's some vision of > "dirtiness" propagating from Instance to Collection.
There is now, yes. > However, I think > it would make sense if dirtiness propagated up the containment > hierarchy. E.g. User dirties a Split, which dirties the split's > Transaction, and Account, which dirties the account's Group, which > dirties the Book. Why such a tortuous path? Split -> Collection -> Book. Checking the book automatically checks all collections. The Book won't know WHICH split has been changed so you gain nothing. 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. These backends could identify which collections are dirty in the book - then identify which instances are dirty by *only* having to iterate over a those collections, instead of all collections and thereby all instances. In your example, the backend would only have to iterate over the Splits, not the entire book. If you make Group dirty everytime a Split is changed, you lose all ability to identify *which* instances are actually dirty. > Now, a check for the need to save can just check > the book. With the new qof_instance_set_dirty() that will be done in one call. > And, the code that commits changes and clears the dirty > flag could also travserse the tree instead of committing whole > Collections, or searching in a Collection for the single split that was > dirtied. Ah now that would be slower. No point, as I see it, traversing the entire tree - set the collection to clean and all done. The QofCollection dirty marker is a single boolean for the entire collection, it does not require iterating through the collection itself, either to set or to clear. > Incidentally, why does Split not even have a dirty flag? I'll be changing that - every object will use qof_collection_is_dirty and qof_collection_make_clean in their object definitions. > What design > decision governs whether a core engine object should derive from > Instance or Entity? ?? All core structs contain a QofInstance which itself contains a QofEntity. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgppPHmxcIghy.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
