GDA: problem when modifying a transaction split

Chris Shoemaker c.shoemaker at
Thu Dec 7 11:14:08 EST 2006

On Thu, Dec 07, 2006 at 10:49:49AM -0500, Phil Longstaff wrote:
> On Thu, 2006-07-12 at 10:39 -0500, Derek Atkins wrote:
> > Phil Longstaff <plongstaff at> writes:
> > 
> > > If I open a register, modify a split and then try to record the modified
> > > transaction, the back end receives a commit call for the transaction,
> > > not for any splits.  However, the transaction is not dirty.  I don't
> > > really want to special case this (though queries for splits are already
> > > special cased).
> > 
> > The Splits, however, ARE marked dirty...
> Yes, but the only commit received by the backend is for the transaction.
> I have special-cased this for now so that if a clean transaction is
> commited, the splits are checked and any dirty ones are committed.
> However, see my other e-mail re a deleted split.  When I receive the
> commit request, deleted splits are not children of the transaction any
> longer, so I have no way of knowing they should be deleted from the db.

IMO, the way this should work is that the dirty or deleted splits
should be committed upon xaccTransCommitEdit().

NOTE: The transaction *does* know which splits should be deleted at
commit time.  Search trans->splits for each split where (s->parent ==
trans && s->inst.do_free).


> I could change my special-case so that all transaction commits occur
> whether the transaction is clean and dirty since a transaction commit
> involves deleting all splits for the tx in the db and then saving them
> again (+ all slots...).  I've been trying to optimize db access as much
> as possible, but this just expands it.
> An alternative is change how the register commits changes but this gets
> into completely new areas of the code.

You _really_ don't want to go there.


> Phil
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

More information about the gnucash-devel mailing list