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

[Derek Atkins]

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

> On Mon, Feb 06, 2006 at 03:37:11PM -0500, Derek Atkins wrote:
>> So it's somewhat questionable at this point if we want splits to be
>> dirtiable
>> or not.  At some level, yea, they should be.
>
> Yeah, I'd say this is true at the persistence-level.  I.e. I really
> don't have to have to read/write the whole trans + all splits when
> only the description of one split has changed.

I'll ponder this for a bit...

>> 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.
>
> Yeah, I'd call this the engine-API level.  Committing _just_ a split
> doesn't and shouldn't make sense at the engine-API level.

Okay, that's certainly fair..  Just so long as it's well documented
where it belongs, who calls what, etc.  We need a well defined calling
invariant as well as a clear event model upwards to the UI (GncEvent)
and down to the backend (begin/commit-edit).

>> 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 think it's better to allow Splits as first-class objects.  Then we
> at least have the _option_ of using a DB schema that treats Splits
> separately from Transactions.  ISTM, that's the most reasonable way of
> handling Transactions with variable numbers of Splits.  How would the
> existing SQL handle more than 2 Splits per trans?

The API only handled transactions; the SQL code stored splits in their
own table.  So at the DB Schema level, yes, splits were still first class
objects.  But at the Engine API level they are (were?) not.

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