QFX import problems

[Derek Atkins]

Benoit Grégoire <bock at step.polymtl.ca> writes:

>> > Well, since I was told at the time not to use the engine's revert
>> > function, there isn't much choice is there...
>>
>> What "engine's revert function"?
>
> xaccTransRollbackEdit()

This only works if you run it before you xaccTransCommitEdit().  It
doesn't remove a transaction, nor does it undo a commit..  It just
reverts back to the state when you ran xaccTransBeginEdit(), which has
no effect in the case of an import because the transactions really
shouldn't "exist" until the import completes.

>> But yes, there is a choice -- you could do what the QIF importer does:
>> not actually create a Transaction* or Split* until *after* the user
>> hit's OK.  Until the user hit's OK the importer makes no changes
>> to the CoA.
>>
>> Basically the import does the following:
>>
>> 1) Duplicate the account tree, and always present the new account
>>    tree to the user when trying to add new accounts or choose existing
>>    accounts.
>> 2) Make all transactions with respect to the duplicate account tree.
>>    Note that these are not really Transaction* objects, but
>> importer-internal objects.
>> 3) Once the user is done and clicks "finish" or "ok" then merge back
>>    into the real CoA...  Create new accounts as necessary, and create
>>    the Transaction*s.
>
> That used to be WAAY too much work.  Maybe now that we have a common framework 
> for the importer it would be worth it.  

Agreed..  I'm hoping we can move some of this there.

> Still, you have to admit that if I could just xaccTransRollbackEdit() to 
> cancel and xaccTransCommitEdit() all at once, we'd have a much cleaner 
> solution.  What good is having an engine if we have to reimplement parts of 
> it each time we want to mess with it's data? 

Agreed, somewhat... At some level "mass import" is really an import
function, not an engine function.  I can't think of anywhere outside
the import modules that need to handle this.  I was hoping that the
generic importer would handle this by not creating the Transaction*
until "late" in the process and using the "generic_transaction" object
instead through the import process...

HOWEVER, we actually need an "undo" operation anyways in QOF.. In
particular once we move to a SQL-backed engine we really want to
"undo" changes..  I don't know exactly how that should work, or at
what granularity.  I can see how it's relatively easy to perform a QOF
"undo" on individual objects, but I'm not sure how to do it en-masse,
ala "undo import".

-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