Hi Ralf:

In message
<1509704965.32.0.213398074469.issue2550955@psf.upfronthosting.co.za> ,
Ralf Schlatterbeck writes:
>Ralf Schlatterbeck added the comment:
>I can finally reproduce this. When I have a web action with a handle()
>method like 
>
>    def handle(self):
>        cl = self.db.getclass(self.classname)
>        cl.set(self.nodeid, status = self.db.status.lookup("feedback"))
>        cl.set(self.nodeid, title = "Just a test")
>        self.db.commit()
>
>and we have an auditor (or reactor) that prevents the title change with
>a Reject exception

Umm, I thought raising reject in a reactor was useless? By the time
the reactor runs the data is committed to the database.

>then the first change (setting the status) will be committed. Note
>that the commit() in handle() is never reached because
>the second set() call will raise Reject.

Agreed.

>Note that the two changes above will not usually be for the same
>class (they could be combined into a single set call which is what
>the web-interface does when changing several values).

Right you expect a transaction that is either atomically applied
across multiple tables/classes or rolled back. No split changes like
you describe.