Welcome back

[Linas Vepstas]

On Thu, Aug 19, 2004 at 09:28:31PM +0100, Neil Williams was heard to remark:
> On Wednesday 18 August 2004 3:10, Linas Vepstas wrote:
> > The GUI that uses book-merge needs to make a copy of the book first.
> > If the merge is aborted mid-way, you still have a copy of the original.
> > Yes, this sounds cpu-sucking to me.   And we don't have an
> > infrastructure for making copies at this time.  So we'd need to deal
> > with that ...
> 
> From the backend docs:
> "In the current design, a session may hold multiple books. For now, exactly 
> what this means is somewhat vague, and code in various places makes some 
> implicit assumptions: first, only one book is 'current' and open for editing. 
Well, I wrote those words back-when, with narry a thought about 
holding duplicate copies of a book.   So this is terra incognito

> QofSession *s1 = qof_session_new();
> QofBook *targetBook = qof_book_new();
> qof_session_begin ( s1, targetBook, "target_id", FALSE, FALSE);
> // so far, simulating what happens already?
> // then add:
> QofSession *s2 = qof_session_new();
> QofBook *importBook = qof_book_new();
> qof_session_begin ( s2, importBook, "import_id", FALSE, FALSE);
> qof_session_swap_data(s2, s1);
> qof_session_end (s2);
> 
> 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.

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?

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.   For the SQL backend,
we will need to have an 'undo' feature, the details of which are TBD,
and which you would best ignore at this time.

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933