Phil Longstaff <[EMAIL PROTECTED]> writes:
>> The Splits, however, ARE marked dirty...
>
> Yes, but the only commit received by the backend is for the transaction.
Yes, because Splits aren't first-class objects. You can't have a
Split without a Transaction.... So historically you commit the Txn
and it automatically handles all the splits, too.
> 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.
> 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.
As I said, it has nothing to do with the register, but the engine.
> Phil
-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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
