[Gnucash-changes] Spruce up the delete window dialog to make it
more HIG compliant.
c.shoemaker at cox.net
Wed Jul 20 19:57:49 EDT 2005
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
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?
> 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
> 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
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel