[jira] [Updated] (OAK-781) Clarify / fix effects of MISSING_NODE as base state of NodeBuilder

["Jukka Zitting (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated OAK-781:
------------------------------

    Attachment: memorynodebuilder-2.png

Updated patch in https://github.com/jukka/jackrabbit-oak/commit/55afcf2fe2d5b9f1c07e3ee80d4d3612f31eef41. It replaces the {{headRevision == -1}} check by splitting the {{head}} variable into separate {{readHead}} and {{writeHead}} variables, the latter of which is of type {{MutableNodeState}}.

Still, the state tracking conditionals remain somewhat scattered around the {{MemoryNodeBuilder}} class. Stepping back a bit it occurs to me that we're really trying to fit together three somewhat separate concerns here:

* Implementing the {{NodeBuilder}} interface
* Keeping track of the connectedness state of the builder
* Managing the shared state of all modified content

Originally the middle concern was a part of {{MemoryNodeBuilder}} and now it's mostly done in {{MutableNodeState}}, especially with the {{connect}} argument to {{getChildNode()}}. My patch is trying to push that concern back to {{MemoryNodeBuilder}} in an attempt to keep the role of {{MutableNodeState}} cleaner.

With that in mind, it occurs me that what we'd really need here is a separate abstraction for explicitly tracking the connectedness state of a builder. We could for example use the state pattern to represent the distinct connected and unconnected states of a {{MemoryNodeBuilder}} instance. The {{MemoryNodeBuilder}} class would remain responsible for tracking the base but would delegate tracking of the head to the connectedness state, implemented as (nested) classes like {{UnconnectedHead}} and {{ConnectedHead}} that would implement a {{Head}} state interface.

The {{UnconnectedHead}} state would encapsulate the current {{headRevision}} logic and the mechanism for connecting a builder to a shared {{MutableNodeState}} instance when needed. At that point the {{ConnectedHead}} state would take over and transparently direct all further content accesses to that shared {{MutableNodeState}} instance.

As an additional benefit of such a structure, we could explicitly model a {{RootHead}} state that's always connected and that could keep track of the {{headRevision}} counter of the root builder. That way we wouldn't need to keep the revision counter around in connected builders where it's no longer needed.

See the attached class diagram (memorynodebuilder-2.png) for an outline of how all these classes would fit together.
                
> 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, memorynodebuilder-1.png, memorynodebuilder-2.png, 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