[Gnucash-changes] Spruce up the delete window dialog to make it more HIG compliant.

Neil Williams linux at codehelp.co.uk
Wed Jul 20 17:25:14 EDT 2005


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/

-------------- 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/e5f52366/attachment.bin


More information about the gnucash-devel mailing list