[
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
