Welcome back

[Derek Atkins]

linas at linas.org (Linas Vepstas) writes:

>> Having a value 'book-merge: NULL,' would be misleading to other developers. It 
>> could easily lead people to think that the object will NOT be merged. Yet if 
>> an object is fully QOF compliant, it's all handled by the book merge routine, 
>> so no special object behaviour is required.
>
> 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).

>> Isn't a merge always going to add data? When would an import result in less 
>> Splits? I've got no code (so far) that removes data from the target book or 
>> any objects in the book.
>
> 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:

1) re-run the hierarchy druid to add more accounts to the existing data file.
2) a generalized case of QIF/OFX/etc. import
3) IIF import (importing more than just transactions)
4) merging husband's and wife's data files into a single data file
5) ...

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available