How to remove all txns from an Account?

[Derek Atkins]

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.

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.

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