jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Different types of 'item modification' on oak-jcr (and oak-api)
Date Wed, 11 Apr 2012 15:41:02 GMT
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


Mime
View raw message