Transactions and splits in the SQL backends

Phil Longstaff plongstaff at rogers.com
Sun Jun 29 12:34:05 EDT 2008


I am running into some difficulties in the SQL/DBI backend related to
transactions and splits.

There are two specific issues which I am trying to balance correctly:

1) If transactions and splits are not marked clean in the "correct"
places, the '*' appears beside the file name and the user is asked to
save the contents,

and

2) If transactions and splits are marked clean in "incorrect" places,
side effects of xaccTransCommitEdit() do not happen (in my case,
recomputing the account balances).

I have "correct" and "incorrect" in quotes because I am not sure where
these places are.  If I try to fix #1, #2 is worse, and vice versa.

Recomputing the account balances happens at the end of the qof_commit2
call from xaccTransCommitEdit(), but does not happen if the splits are
not marked dirty.  Should the check change, so that the account balance
is recomputed if the split's account's balance is dirty rather than the
split being dirty? In trans_commit_edit(), the split is only committed
if dirty, and at the end of xaccSplitCommitEdit(), the
xaccAccountRecomputeBalance() is called.

Somewhat related is the issue of referential integrity.  Theoretically,
it should be impossible to have split records which refer to a
transaction record which doesn't exist.  However, when a transaction is
deleted, the Transaction object is deleted before the Split objects are
deleted.  I can add some referential checks in the back end (so that if
a transaction record is deleted, all of its split records are deleted
first), but that can lead to #1 above.

Is there design documentation on this (complex) part of the code?

Phil



More information about the gnucash-devel mailing list