[
https://issues.apache.org/jira/browse/OAK-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638901#comment-13638901
]
Michael Dürig commented on OAK-781:
-----------------------------------
bq. It would seem like a better idea to use the exists() status of the
underlying base NodeState
Right, hat should do.
bq. it occurred to me that renaming getChild and addChild...
Agreed. IMO we should even rename the rename {{addChild(String)}} to
{{setNode(String)}} since it has the semantics of {{setNode("foo",
EMPTY_NODE)}}.
bq. Thinking more generally about the MemoryNodeBuilder...
I think the current design makes sense in general and fulfils the first two
bullet points above. What we need to do IMO is
* update the Javadoc the current design,
* don't access {{MutableNodeState}}'s state directly but use accessors whose
name capture the intended semantics,
* differentiate between {{read() / write()}} and a new set of methods (e.g.
{{base() / head()}}. The former pair would update a builder's state for read /
write access while the latter pair would update a builder's base / head state.
Currently this functionality is intertwined in {{read() / write()}}.
Regarding moving the purge logic below the {{NodeBuilder}} there is OAK-659. As
stated in the cited [discussion |
http://markmail.org/message/lbc3rx2p3sssvqj5], the transient move operations
are troublesome. Maybe we could use an approach as suggested in OAK-783 and
annotate moved nodes with a reference to their source in their original
revision? I think this should give us enough information to come up with
workable solutions later on.
> Clarify / fix effects of MISSING_NODE as base state of NodeBuilder
> ------------------------------------------------------------------
>
> Key: OAK-781
> URL: https://issues.apache.org/jira/browse/OAK-781
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Reporter: Michael Dürig
> Attachments:
> 0001-OAK-781-Clarify-fix-effects-of-MISSING_NODE-as-base-.patch, OAK-781.patch
>
>
> Having a {{MISSING_NODE}} respectively a node state that returns false for
> its {{exists}} method as a base state of a node builder results in undefined
> behaviour. We need to clarify how to handle such cases for resolving OAK-766.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
