merge procedures

[Neil Williams]

On Thursday 22 July 2004 6:32, Linas Vepstas wrote:
> This is very long email,

I know, I just waffle on sometimes. Sorry.

What I should have asked was:

1. At present, I don't have a way of informing the user of corrupt import data
UNLESS the parameter names, types or values are invalid. However, as the 
functions only accept GNCBook (i.e. QofBook) then it's down to the import 
code to sift out such corruptions, and for my code to not crash noisily if 
some are not caught. Yes?

2. By using the standard set_fcn's from qof_class, the required relationships 
between objects, parent and children can be maintained without separate code. 
That leaves me with exact GUID and non-GUID matches ignored, new data, 
updated data and reported data. The dialog would then allow the user to reset 
each report tag to, duplicate, update or new. Would it be preferable to just 
offer two actions? Import and ignore? (i.e. Import overrules Target or Target 
overrules Import), ala pilot-link.

3. I propose leaving the initial call to gncBookMerge as requiring that both 
books be explicitly specified, import and target. 
There is no intrinsic need (except memory / performance) for gncBookMerge to 
be restricted to only merging into the currently active book - it is possible 
to specify two other books and merge those without affecting the active book. 
The purpose of such a merge is up for debate but it might be useful. 
:-) Is this agreeable?

4. The functions, as they develop, are all QOF based. It's qof_class, 
qof_object, qof_param and qof_entity that dominate the function calls, 
pointer types, callbacks and methods. Would it be appropriate to switch to 
qof_book_merge instead of gncBookMerge? Is a book merge useful as part of QOF 
as well as in GnuCash? 
The only gnc stuff that I've used (I think) is my own gncBookMerge naming 
convention. The code resolves all objects to the bare QOF_TYPE primitives 
using existing qof_class and qof_param routines with only two new structs, a 
new callback and one new enum, so it should be completely generic. (It will 
generate an error if a type is unrecognised).

5. The outline of the dialog control procedure is now working - it's 
implemented as a callback for each rule that needs user intervention. There's 
an Init() call with the two QofBook pointers, the callback over each compared 
rule and a Commit() operation. If anyone has some time to work on the GUI 
code, I would be very grateful. My testing will continue in console mode for 
now - would this be at all useful in the final code, to be able to pass two 
GnuCash files and output a merged file with the same collision handling, all 
on the command line? 

I've got lots more work to do on the comparisons and on all the set_fcn calls 
in Commit() but it's looking a lot better than it did. (i.e. it's maybe 50% 
but it ain't near finished yet!!)

(I'm waffling again)
> please cut-n-paste it into your documentation somewhere.
> Dumping it to a file in src/docs is sufficient if you are lazy.

It's in the docs already, just phrased differently. I'm constantly reviewing 
the docs and I want to reduce the amount of waffle and duplication as the 
details are worked out. (So I've got plenty of work there too!)

> > PS: What is in KVP parameters? e.g. in Account, what would be contained
> > in the QOF_TYPE_KVP parameter?
>
> Assorted misc data.  Voided transactions are marked as such in the kvp
> data.  I think account tax info is stored in the kvp.  KVP is a simple
> catch-all for data that people need to store when they add new features,
> without having to go through the pain of modifying the core structures.

OK, thanks. I'll add some suitable comparisons so that it can be handled 
better.


-- 

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/20040722/672bb6bf/attachment.bin