jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Different types of 'item modification' on oak-jcr (and oak-api)
Date Wed, 11 Apr 2012 16:30:20 GMT


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
>

Mime
View raw message