[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