[Gnucash-changes] r13132 - gnucash/trunk/src/engine - Keep QOF aware of the dirty-state of Transactions.

Derek Atkins warlord at MIT.EDU
Mon Feb 6 15:37:11 EST 2006


Quoting Chris Shoemaker <c.shoemaker at cox.net>:

>> I admit I haven't looked at the code recently..  Part of the issue is that
>> in XML the Splits aren't listed on their own -- they only exist within
>> a Transaction -- so you kinda need to mark the transaction as dirty when
>> you change a split.
>
> Yeah, I don't know why, but, looking at the code more closely, we
> don't even actually keep dirty state on Splits at _all_.  mark_split()
> just flags the account _balance_ and _sorting_ as dirty.  I don't see
> any good reason not to actually keep dirty state for the splits.  Then
> you can ask a transaction if it has dirty splits, something we can't
> currently do.

It's somewhat historical.  Obviously none of this really matters for
the xml file backend.  In the current SQL backend, the interface really
is (was?) limited to Accounts and Transactions.  There were no "Splits"
in the interface.  You stored a transaction en-masse, not a split.  So
a "dirty split" didn't matter; a split was just a part of a transaction
and couldn't live by itself.

That's why we never dirtied splits; a dirty split just dirties the transaction
and that way the full transaction is written to the DB and accounts can
be updated etc.

So it's somewhat questionable at this point if we want splits to be dirtiable
or not.  At some level, yea, they should be.  But at another, we necessarily
WANT splits to be committed or rolled back together with a full transaction,
not individually..  So we DO want it based on xaccTransBeginEdit/CommitEdit,
and not introduce an xaccSplitBeginEdit/CommitEdit.

I suspect that's also why the Split used the QofEntity instead of QofInstance,
because the Split didn't want its own last_update or dirty flag -- it's
inherited from the Transaction.

>> I'm not sure in what cases you ever want to or need to mark a split
>> dirty just because the transaction changed.
>
> Well, like I said, the two existing cases are actually just dirtying
> computed-state (not stored-state) in the Account.  I think they're
> both correct: changing the trans date, and the trans currency.  But, I
> don't think these cases should ever dirty the stored-state of the
> Account, and I think it should dirty the stored-state of the Split iff
> the split value has to be re-expressed in a new denominator.

Changing the trans date or trans currency need not dirty the account
stored state.   However they obviously need to dirty the txn stored state.

>> (I'll note that we still need the xaccAccountInsertSplit(), but I think that
>> only should be called "interally" by xaccSplitSetAccount(), and it doesn't
>> necessarily need a begin/commit edit because it's only structural data,
>> not real data).
>
> Exactly.  I'd be more emphatic.  s/doesn't necessarily/really shouldn't/  :)

Sure..  :)

> -chris

-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