QFX import problems

Derek Atkins warlord at MIT.EDU
Thu Aug 5 23:24:06 EDT 2004


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

> Well, there is already code in the importer that, at the very end, either 
> commits every transactions still flagged to be imported, and deletes (and 
> commits) every other.  Trouble is the engine doesn't handle (well, so I was 
> told) reverts cleanly enough to change it to commit transactions to be 
> imported, revert others.

What does it mean to "Rollback" a transaction that you're "importing"?
It's not supposed to have hit the CoA yet, so there's nothing to
revert.  You definitely want to "destroy" at this point..

But a better approach is to not even allocate the transaction until
after the user hits ok.

> Well, you don't need an "undo import".  You necessarly still have pointers to 
> every transactions untill the very end of the import process.  As long as you 
> didn't commit, you can revert objects individually by walking the list.  
> That's already what the code does to do the commits.

Yes, but what if the user decides they didn't want to import it after
they clicked "OK"?  Perhaps we just don't care, but I've certainly
performed many tests where I perform the import and then exit without
saving.  Once we have the SQL backend I wont be able to do that
anymore, so I'd like an "undo".

> Maybe one day I'll have time to look into this.  At worst, there's only few 
> decades left till retirement ;)

Hehe..

> Benoit Grégoire, http://benoitg.coeus.ca/

-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



More information about the gnucash-devel mailing list