qof_commit_edit_part_2 commit, then delete

[John Ralls]

On Nov 28, 2013, at 2:05 AM, Christian Stimming <christian at cstimming.de> wrote:

> Am Mittwoch, 27. November 2013, 16:45:03 schrieb John Ralls:
>> As it now stands, we run the commit code, then check priv->do_free and run
>> the destroy callback if it’s true.
>> 
>> Wouldn’t it make more sense to *not* run the commit code if we’re destroying
>> the instance?
> 
> Yes, this would make more sense.
> 
> On another note, the whole semantics of begin_edit, commit_edit and so on seem 
> still only half-implemented to me. If you or anyone else can come up with a 
> better design here, preferably covered by unittests, I'm all for this as well.

The semantics are right: They're lifted directly from the RDB terms for the same actions. 

They can be somewhat simplified by more closely coupling with the RDBMS so that the objects don't need to be copied at start edit to be able to roll them back. A rollback can be accomplished by simply dropping the in-memory objects and reloading them from the DB. Deeper rollbacks ("undo") might be done with the RDBMS's checkpointing and rollback facility. I'm less sure about that.

Unit tests are already in place for Account, Transaction, and Split. Much of the rest of engine is reasonably well-tested, but the tests are in the old home-grown framework and need to be converted and evaluated for coverage.

Regards,
John Ralls