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 |