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

[Chris Shoemaker]

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.

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

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

-chris