Welcome back

Linas Vepstas linas at linas.org
Wed Aug 18 09:17:59 EDT 2004


On Wed, Aug 18, 2004 at 12:15:06AM -0400, Derek Atkins was heard to remark:
> linas at linas.org (Linas Vepstas) writes:
> 
> > Can't we just move the merge function out of the book-merge routine, and 
> > put it into the per-object routine?  
> 
> I'm not convinced this always works.  Sometimes I think you need
> multi-object merges (c.f. Transactions v. Splits, which are separate
> QOF objects but should probably get merged as a 'transactional' unit).

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.

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.

> > I'm not sure I understand how merge will be used.  I think Derek is
> > thinking about a conflict case, where there are two transactions that
> > should be the "same" transaction, and thus should be "merged" (?) 
> > except that one transaction has 2 splits and the other has 3.   
> > Clearly the "right answer" is not necessarily a transation with 3
> > splits.  Prusmably, the "correct answer" is to have the user pick one 
> > of the two transactions, and throw the other (and its splits) away.
> >
> > In this case, we don't want to run "object-merge" on the two
> > transactions at all... 
> 
> I can think of multiple uses:

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, 
and what part of the logic is implemented in the GUI code.  I'd like to 
see teh overview pseudocode (is it on some web page I've managed to
ignore?)

--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


More information about the gnucash-devel mailing list