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
pgpf4nSNu5rcu.pgp
Description: signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
