[
https://issues.apache.org/jira/browse/OAK-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16917572#comment-16917572
]
Vikas Saurabh commented on OAK-8579:
------------------------------------
[~tmueller], I was thinking about this issue after we discussed "fix validator
approach". I wonder if another way could (should??) be for diff to not report
"magically appearing node to not be reported in {{childNodeAdded}}". I do see
that this is more hacky - but what I'm really trying to evaluate "should this
new type of node incarnation be treated differently than simple child node
addition". wdyt?
> 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)
