[Gnucash-changes] Spruce up the delete window dialog to make it
more HIG compliant.
linux at codehelp.co.uk
Wed Jul 20 15:19:40 EDT 2005
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
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050720/f13464e4/attachment.bin
More information about the gnucash-devel