Welcome back

Neil Williams linux at codehelp.co.uk
Wed Aug 18 14:22:08 EDT 2004


On Wednesday 18 August 2004 2:17, Linas Vepstas wrote:
> Sure ... in this case, the split-merge routine would be a no-op, and
> the transaction-merge routine would do the 'real' work.  Nothing wrong
> with that, as long as (for example) the currency-merge routine doesn't
> have to know about splits.

With a book level merge, no object knows about any other UNLESS the object 
already contains a parameter of that object type. That is why I need a 
merge-helper section in specific objects.

> Also, I think that doing it this way would help resolve order
> dependencies: so that currencies are merged before accounts, accounts
> are merged before transactions, etc.  rather than having things mereged
> in some random order.

1. All new entities are created before any entities are updated.
2. All editing is prevented until all entities are updated.
3. Where specific lists exist for specific objects, these can be updated using 
helper code, if necessary, at the end of the commit.
4. Any object, like an account, that relies on another object, like a 
currency, retains a reference to the other object in the ruleset. The 
reference becomes valid once the other object is assigned. Provided that no 
edits are allowed during the commit, all references will be valid at the end 
of the commit. If any tidying-up is required, it can be run after the commit 
and before control is handed back to GnuCash for editing to resume.

(The example in 4 is, naturally, dependent on resolving problems with 
gnc_commodity and QOF).

> Sorry, I meant to imply  "I don't understand the algorithmic steps that
> are taken during merge, specifically in the case of conflict resolution".
> I don't understand what part of the algo is done in the engine merge code,

100% in qof_book_merge.c

This is split between the Compare routine (80%) and the UpdateResult (10%) and 
UpdateRule (10%) functions. Essentially, the merge is front-loaded.

Specifically, the logic is divided into two utterly discrete segments:
1. If there is a GUID match.
2. If there is no GUID match.

Everything in the compare in segment 1. runs faster, with less system demands 
and less user reports than anything in the compare in segment 2.

The more import objects that contain a GUID match, the more qof_book_merge.c 
code is simply ignored. This is a strong argument for ensuring that every 
export format contains the original GUID and retains that into any subsequent 
import QofBook.

> and what part of the logic is implemented in the GUI code.

0%. The GUI is just there to display and retrieve the user intervention 
results. It gets strings from the merge code, it sets a few enums. End of 
story. All the logic is in the merge. If a user routine tries to set a dumb 
result, it will be ignored or reset.

I'm treating the GUI as a dumb terminal. This allows the qof_book_merge code 
to be used in console applications. After all, there is nothing in QOF that 
requires a GUI, so I didn't see why a qof_book_merge had to insist on a GUI 
either. I've designed the merge to be able to use any current or future 
method of user involvement. It could even work with touch-screens, braille or 
text-to-speech interfaces.

All I need is for the user to be able to understand the data involved in the 
collision and to report their decision on how to resolve the conflict.

In exampleGncBookMerge.c, I offer the user three choices:
1. Allow the import object to completely overwrite the target object.
2. Ignore the import object and keep the target object 100% unchanged.
3. Set the import object as completely new - existing references will be 
retained so that the object appears as new alongside the unchanged original 
target.

Note that at no time are objects in the target book actually deleted, only 
modified. There may be a role for merge-helper to free an object that has 
become redundant/orphaned but I can't test that yet.

So a Split is updated as one entity, an Account can be modified separately 
from all transactions. (This works because the only parameters of an account 
that CAN be modified are those that are NOT calculated from transactions - a 
merge will never change the balance of an account by changing the account - 
only by changing the transactions.)

A customer can be updated with no changes to the invoices - the new or 
modified data will show up whenever the invoice itself is processed or a new 
invoice created.

> I'd like to 
> see teh overview pseudocode (is it on some web page I've managed to
> ignore?)
http://www.codehelp.co.uk/code/draftset.html

I've got doxygen and docbook output on codehelp.co.uk/code

I admit I do waffle sometimes and it is probably more wordy than you might 
like. Take a look at the test program and the example program, those should 
be more familiar.

I've used gncAccount and gncInvoice as my two main templates for most of my 
code. test-book-merge is based on test-object.

-- 

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/20040818/31c804ce/attachment.bin


More information about the gnucash-devel mailing list