On Friday 20 August 2004 2:45, Linas Vepstas wrote: > > QofSession *s1 = qof_session_new(); > > Would this give access to targetBook read-write and importBook read-only? > > No. First of all, session_swap_data() is a funked-up concept, and I > was planning on getting rid of it some day. Just keep the two sessions > open, you don't need to swap data between them.
OK. > Hmm. I'm now thinking that making a copy of a book before merging is a > bad idea. ... it presents a number of conceptual problems, and why > introduce problems if they're not really needed? I agree with the sentiment, just don't see how it applies - I don't copy the import book, I just need 2 QofBook's, the import and the existing or target book. With the book level merge, I need the import book AND target book available from the beginning, right through to the end - simply because I don't copy the import book before or during the merge, I just have two books open. The comparison reads import and target (for all entities in the import book), sets an enum and tracks the QofEntity pointers - no parameter data is actually copied. The user intervention routine reads import and target (for only those entities that need intervention), sets an enum and maintains the tracked QofEntity pointers that link the import and target books. The commit routine (for only those entities that are new or need to be modified) reads the import and sets the target book. So at each stage, I need at least read access to both books, but no copies. Each stage uses a different sub-set of each book. Only the initial compare reads all the import data. Each subsequent stage iterates over less entities. Each parameter value pair (one from import, one from target) is retrieved and either compared, displayed or set before being overwritten with the next pair. The merge process builds the glue, the links that allow the user to see what needs to be resolved and tells the commit which entities are to be updated, which are new and which should be ignored. Basically, it spends most of the time saying that this QofEntity in the import book is linked with that QofEntity in the target book and working out what to do with it. I do as little copying as scope will allow. I had originally planned to create a temporary QofBook and that would have involved copying data. Derek mentioned early on that holding the merge data in a third QofBook in this way would be wasteful, so I wrote a bespoke struct that holds only a few GSList's and the all important QofBook pointers. The lists hold the rules that tell the commit which entity in the import book to use with each entity in the target book. The entities themselves are not copied. > The file backend has an 'undo' that works by simply not saving the > changed book. So, to abort a merge, you simply don't save; instead, > you can re-read the original data from the file. This could be used after the commit - giving the user a chance to proof the merge before saving the book. The merge itself will not issue a 'Save' command to any backend, that's for the user to do. -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
pgp5QD6tklscR.pgp
Description: signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
