linux at codehelp.co.uk
Thu Jul 22 14:50:53 EDT 2004
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040722/672bb6bf/attachment.bin
More information about the gnucash-devel