How to remove all txns from an Account?

[Charles Day]

On Tue, Apr 15, 2008 at 12:58 PM, Derek Atkins <warlord at mit.edu> wrote:

> Charles,
>
> Quoting Charles Day <cedayiv at gmail.com>:
>
>  On Tue, Apr 15, 2008 at 11:32 AM, Charles Day <cedayiv at gmail.com> wrote:
> >
> >  On Tue, Apr 15, 2008 at 10:56 AM, Derek Atkins <warlord at mit.edu> wrote:
> > >
> > > > Hi,
> > > >
> > > > I think the real question is.. What EXACTLY are you trying to do?
> > > >
> > >
> > > I'm trying to fix bug 512208. Right now, if the user cancels a QIF
> > > import,
> > > the imported account tree is not destroyed.  To fix this, upon
> > > cancellation
> > > I want to first remove all transactions from the imported account
> > > tree. This
> > > removes all their splits too and, crucially, avoids the possibility of
> > > leaving splits in an Imbalance account in the existing GnuCash account
> > > tree.
> > > After that, I'll need to remove the imported accounts themselves and
> > > any new
> > > commodities created by the importer (both easy).
> > >
> >
> It's not done because 99% of the time it's just additional overhead.
> Why build up a GList just so you can iterate over it and then destroy
> it when you can USUALLY just perform the iteration the first time.
> It turns your O(n) into O(2n) process.  Granted, this is still O(n)
> but it DOES double the time.  Also, g_list_append() is O(n) so you wind
> up making it an O(nlogn) solution.
>

OK, then we should very publicly document the dangerous trade-off: that the
transaction callback function must never modify the account assigned to any
split in the transaction, or destroy any split in the transaction, as doing
so risks a crash.

If you like, I can add that to the doxygen documentation in Account.h.

I also didn't think you could cancel the import after you reach the
> qif-to-gnc functionality.  But still, there shouldn't be any transactions
> except those you've just imported.  You already have a handle on those
> transactions so just delete them.  Yet I'm still not sure how this can
> happen unless the qif-to-gnc is happening too early.
>

You can still cancel the import after the qif-to-gnc stage by clicking
Cancel on the final page of the druid instead of Apply. It is also necessary
to cancel in cases where the qif-to-gnc functionality catches an exception
(see my fix for bug 509089).

When the Cancel button event is caught by the C handler, there is no
already-built list of transactions. But either C or Scheme could build one
based on the root account of the imported tree, which is known.

If I have to build my own list of transactions for a given account tree, is
a QOF query perhaps the fastest way to go? There is already a routine
written with this strategy in Scheme (gnc:account-tree-get-transactions in
qif-merge-groups.scm).

Cheers,
Charles

> > What I would do:
> > > >
> > > >  xaccAccountTreeForEachTransaction(acc, get_txn_list_cb, &txn_list);
> > > >  foreach (txn_list)
> > > >     delete txn.
> > > >
> > >
> > > I'm wondering why xaccAccountTreeForEachTransaction() doesn't build
> > > that
> > > list of transactions on its own, before calling the provided callback
> > > function. Instead, it walks through the list of each account's splits
> > > and
> > > assumes that the list element it is it working on doesn't disappear
> > > out from
> > > under it (which it does, if the callback deletes the split, resulting
> > > in a
> > > crash).
> > >
> > >
> > Crashing is also a possibility if the callback function reassigns the
> > split
> > to a different account.
> >
>
>
> I haven't looked at the implementation, but one should be able to grab
> the 'next' pointer before calling the callback which should fix most
> of these issues.
>
> -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
>
>