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.
similarly, the TransientNodeState looks in this respect a bit
odd to me as 'transient' and 'state' could be looked at as
controversial concepts.
kind regards
angela
