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

[Chris Shoemaker]

On Wed, Jul 20, 2005 at 10:16:32PM +0100, Neil Williams wrote:
> 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. 

Ok, this was my point.  I completely understand that you can get a
very quick boolean answer to the question "has anything in the book
changed?" by checking each collection's dirty flag.  But think about
*how* you'd have to create a list of all dirty entities for the case
where the task is to commit just the 1 split that changed in my
example.  ISTM (It seems to me) there are 3 options: 1) You can't do
that; you must commit all 100000 Splits.  2) You can do that just
fine, but you must do a linear search through 100000 Splits to find
the 1 that changed.  or 3) You start at the dirty book, and perform
the tree search I described before.  The time cost difference between
2) and 3) can be arbitrarily large.

I can see that QSF only needs to handle lists of uniformly typed
entities.  However, if there's no way to ask "are there dirty
Transactions in this Account", then *every* selection of a subset of
Splits for commiting will require a linear search through *all*
Splits.  Does that seem like a problem to you?

-chris

> 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/
> 



> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel