Welcome back

[Neil Williams]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040820/91334949/attachment.bin