[
https://issues.apache.org/jira/browse/OAK-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16917558#comment-16917558
]
Thomas Mueller commented on OAK-8579:
-------------------------------------
> inadvertently ignoring/skipping some needed check here
[~nitigup] the changes only affect hidden nodes
(NodeStateUtils.isHidden(name)). With the JCR API it is not possible to create
or access hidden nodes. So I believe it is not a risk.
> we can reproduce this and see why this check is only coming into picture when
> index is getting created in read only part of the repo
This we know. But it is good to explicitly describe the problem: assume you
create an index exists in the read-only part of the repo, using the "composite
seed" mode, then the some hidden nodes are created by indexing. But only in the
so called "read-only" repository. It is not actually read-only in this mode.
But it is stored in a different segment store. If you investigate, for example
with oak-run explore, how this repository looks like, you would see something
like this
{noformat}
/oak:index/abc
/oak:index/abc/:oak:mount-readOnlyV1-index-data
{noformat}
It is not yet created in the read-write repository. So when starting the
composite store that opens the read-only repo in read-only mode, and the
read-write repo in read-write mode, the nodes above are not visible.
Now, assume you create an index in the read-write repo with this name:
{noformat}
/oak:index/abc
{noformat}
It is not yet indexing at that time, just storing the node itself. (Possibly
you could even create a node of any other type, for example nt:base, so not an
index definition node - I didn't test). What happens is: the hidden node
/oak:index/abc/:oak:mount-readOnlyV1-index-data will now become visible, due to
how the composite node store works and is configured. For Oak, it will looks
like the node /oak:index/abc/:oak:mount-readOnlyV1-index-data was just added by
the user (which is impossible to do using the JCR API, but the Oak verifiers
don't know that).
So the verifiers currently check if this node is a correct JCR node. It's not:
the primary type is not set, so is "null".
To resolve this issue, I changed the verifiers to ignore hidden nodes.
> Composite Node Store: Allow creating an index in the read-only repo first
> -------------------------------------------------------------------------
>
> Key: OAK-8579
> URL: https://issues.apache.org/jira/browse/OAK-8579
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite, core, indexing, lucene
> Reporter: Thomas Mueller
> Priority: Major
>
> Currently, it is not allowed to first create a new index in the read-only
> repository, and then in the read-write repository. Trying to do so will fail
> with "OakConstraint0001: /oak:index/.../:oak:mount-readOnlyV1-index-data[[]]:
> The primary type null does not exist"
> See OAK-7917: oak-lucene/src/test/java/org/apache/jackrabbit/oak/composite -
> CompositeNodeStoreLuceneIndexTest.java
> tryAddIndexInReadWriteWithIndexExistinginReadOnly line 112.
> It would be better to allow this use case, to reduce the possibility of
> problems.
> We should specially test with lucene indexes, but also with property indexes.
> (If that's more complicated, we can concentrate on the lucene case first.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
