Item state represents the state of an in-memory item. This has nothing
to do with the state of the item in the backend.
Referring to the JCR spec (21.3 Save vs. Commit) a transaction rollback
or commit will not change the in-memory state of items, but only the
backend.
When a transaction is rolled back, we try to correct the state of
in-memory items so that the session could be correctly saved if no more
constraint violations remain. Note that this does not fully work yet.
On Item::beginTransaction() we save the current state into savedState.
On a rollback, we basically go back to the saved state, with a couple of
exceptions. The following table shows an ordered list of rules - the
first match is used. The * denotes any state.
| # | $savedState | $state | Resulting $state |
|---|---|---|---|
| 1 | DELETED | * | DELETED |
| 2 | * | DELETED | DELETED |
| 3 | NEW | * | NEW |
| 4 | * | MODIFIED | MODIFIED |
| 5 | MODIFIED | * | MODIFIED |
| 6 | CLEAN | CLEAN | CLEAN (if the item was not modified in the TRX) |
| 7 | CLEAN | CLEAN | MODIFIED (if the item was modified in the TRX) |
| note: case 7 is handled in Item::setState() by changing $savedState to MODIFIED if $savedState is CLEAN and current state changes to MODIFIED Without this special case, we would miss the situation where a clean node is modified after transaction start and successfully saved, ending up with clean state again. it has to be modified as its different from the backend value. | |||
| 8 | CLEAN | DIRTY | DIRTY |
| 9 | DIRTY | * | DIRTY |
| public rollbackTransaction ( ) |
/**
* {@inheritDoc}
*
* Additionally, notifies all properties of this node. Child nodes are not
* notified, it is the job of the ObjectManager to know which nodes are
* cached and notify them.
*/
public function rollbackTransaction()
{
parent::rollbackTransaction();
foreach ($this->properties as $prop) {
$prop->rollbackTransaction();
}
}
