On 11.4.12 16:41, Angela Schreiber wrote:
hi thinking about how to implement the various JCR level operations that are beyond regular item modification, i found that IMO will face at least the following 4 types of writing that would from a oak-api point of view may just look like item state modifications: a) Regular JCR Item Modification - transient modification on jcr items - example: Node.addNode, Item.remove, Property.setValue etc. - effect on oak-jcr: > Item or parent item is modified or new > Session has pending changes - effect on oak-api: > changes are not yet persisted and not visible on oak-api but only upon Session.save() b) Special JCR Item Modification: - transient modifications on jcr items through other API associated items may e.g. be protected - example: AccessControlManager.setPolicy, User.changePassword - effect on oak-jcr: > Item or parent item is modified or new > Session has pending changes - effect on oak-api: > changes are not yet persisted and not visible on oak-api but only upon Session.save() c) Non-Transient JCR Item Modifications: - workspace level jcr item modifications - example: Node.checkin, Workspace.clone, Workspace.move - effect on oak-jcr: > Item or parent item is neither modified nor new > Session doesn't have pending changes > changes are never visible as transient modification > no Session.save() - effect on oak-api: > either changes are directly passed to oak-api or there exists separate API methods on oak-api to cover these operations. d) Non-Transient Special Item Modification: - workspace or 'repository' level item modifications for special JCR functionality we may represent as content on lower levels - example: registered node types represented as jcr items under /jcr:system/jcr:nodetypes assuming that registration was mapped as simple item modification. - effect on oak-jcr: > Item or parent item is neither modified nor new > Session doesn't have pending changes > changes are never visible as transient modification > no Session.save() - effect on oak-api: > item modifications changes are directly passed to oak-api and validated, persisted accordingly when looking at the current oak-api and the NodeStateEditor i don't see how we would currently be able to distinguish these different types.
The current API should be able to cope with transient modifications and non-transient modifications. The latter can be done by obtaining a new connection just for those changes.
Regarding the "special modifications" we still need to come up with a way to handle those. They should IMO also be done through the Connection, NodeEditor, etc. interfaces which might need to be tweaked accordingly.
similarly, the TransientNodeState looks in this respect a bit odd to me as 'transient' and 'state' could be looked at as controversial concepts.
The name reflects "transient" from JCR and should emphasis the fact that instances of this class are - in contrast to NodeState - not Immutable. However, we could rename this not MutableNodeState or something different if you prefer.
Michael
kind regards angela
