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

[Neil Williams]

On Wednesday 20 July 2005 9:28 pm, Chris Shoemaker wrote:
> So you're saying that somehow, I don't have to search through 100000
> Splits

Correct. When checking if the book is dirty, the object types are checked - 
one type at a time. There are less than two dozen object types in GnuCash. 
The call is to qof_collection_is_dirty() which reports back if it's internal 
gboolean is TRUE or FALSE. End. No instances are searched.

That flag will now be set via qof_instance_set_dirty so that as soon as you 
edit any Split (or whatever), the QofCollection for GNC_ID_SPLIT is marked as 
dirty. Each object type only has one collection per book so if any one of 
those splits is changed, the collection is marked as dirty and none of the 
splits need to be checked.

> and I don't have to commit every Split

The SQL will commit the changes as they happen. For the XML, currently, yes 
you do have to commit them all but that may change. QSF could easily cope 
with committing only those entities that have changed - all it needs is a 
list. If that was desirable, the list could be created as a secondary 
collection. (Secondary collections are the basis of QOF_TYPE_COLLECT and can 
hold any selection of entities (>=1) that match the collection type, 
irrespective of how many exist - primary collections always hold *all* such 
entities that exist in the book. Unless stated otherwise, collections are 
deemed primary.)

> , even though I'm only  
> recording dirtiness on the Collection?

You set a Split to dirty in the Split instance, that sets the flag in the 
collection.

When you check to see if an instance is dirty, if the collection is clean, the 
instance sets and reports as clean.

So the recording still happens via the instance but it is triggers a flag in 
the collection, if it's not already set.

> and this is unique to the SQL 
> backend?  Is that because all edits are committed immediately and
> dirtiness isn't even relevant?

To SQL yes, but SQL also uses last_update to only sync those entities that are 
in current usage.

-- 

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