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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
