[
https://issues.apache.org/jira/browse/OAK-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205000#comment-16205000
]
Chetan Mehrotra edited comment on OAK-6831 at 10/15/17 3:03 AM:
----------------------------------------------------------------
bq. I'm not very comfortable with the node type definition. I'd much rather
prefer that we bring in a new index type - internally we can, of course, map it
to the IndexDefinition you described above.
That would be a bigger change and something which I feel we do not require now.
What about we move this {{nodeTypeIndex}} to top level and not at individual
rule level. That would allow us to ensure that no other rule defines property
definitions. So no way to get into ambiguous state
bq. is that it would most likely index data that is not expected in the index
(e.g. OAK-4653 - what nodetype index does). Basically, we should work with all
rules instead of what getApplicableIndexingRule reports.
Note that with current design for following nodetypes
{noformat}
[oak:TestMixA]
mixin
[oak:TestSuperType]
- * (UNDEFINED) multiple
[oak:TestTypeA] > oak:TestSuperType
- * (UNDEFINED) multiple
[oak:TestTypeB] > oak:TestSuperType, oak:TestMixA
- * (UNDEFINED) multiple
{noformat}
If you enable {{nodeTypeIndex}} to true for say {{oak:TestMixA}} then that
would create 2 internal indexRules for {{oak:TestMixA}} and {{oak:TestTypeB}}
(where second is clone of first). -So to handle OAK-4653 what we can do is just
index the indexRule name and not read primaryType and mixinTypes property
values-
Now I get what you mean by intersection - A node being indexed may have been
indexed due to rule r1 but same index definition may be having other nodeType
rules which this node qualifies. So yes to be more precise we would need to
index the intersection
was (Author: chetanm):
bq. I'm not very comfortable with the node type definition. I'd much rather
prefer that we bring in a new index type - internally we can, of course, map it
to the IndexDefinition you described above.
That would be a bigger change and something which I feel we do not require now.
What about we move this {{nodeTypeIndex}} to top level and not at individual
rule level. That would allow us to ensure that no other rule defines property
definitions. So no way to get into ambiguous state
bq. is that it would most likely index data that is not expected in the index
(e.g. OAK-4653 - what nodetype index does). Basically, we should work with all
rules instead of what getApplicableIndexingRule reports.
Note that with current design for following nodetypes
{noformat}
[oak:TestMixA]
mixin
[oak:TestSuperType]
- * (UNDEFINED) multiple
[oak:TestTypeA] > oak:TestSuperType
- * (UNDEFINED) multiple
[oak:TestTypeB] > oak:TestSuperType, oak:TestMixA
- * (UNDEFINED) multiple
{noformat}
If you enable {{nodeTypeIndex}} to true for say {{oak:TestMixA}} then that
would create 2 internal indexRules for {{oak:TestMixA}} and {{oak:TestTypeB}}
(where second is clone of first). So to handle OAK-4653 what we can do is just
index the indexRule name and not read primaryType and mixinTypes property values
> Nodetype index support in Lucene Index
> --------------------------------------
>
> Key: OAK-6831
> URL: https://issues.apache.org/jira/browse/OAK-6831
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.8
>
>
> Lucene indexes currently support nodetype index in some form by specifying a
> property definition for "jcr:primaryType" with propertyIndex=true. However
> this can cause issue if such rules are mixed with other rules.
> For supporting usecase where same lucene index supports multiple nodetype
> rules and can be used as pure nodetype index we should have a explicit
> support for indexing nodetypes.
> *Proposal*
> Any indexRule would support following properties
> * {{nodeTypeIndex}} - Boolean indicating if this rule is for nodetype indexing
> * {{sync}} - If nodetype index is sync
> if {{nodeTypeIndex}} is enabled then any explicit property definition would
> be ignored. With this mode following index definition would be safe to use
> {noformat}
> /oak:index/nodeTypeLucene
> - jcr:primaryType = "oak:QueryIndexDefinition"
> - compatVersion = 2
> - type = "lucene"
> - async = "async"
> + indexRules
> + nt:file
> - nodeTypeIndex = true
> + app:Component
> - nodeTypeIndex = true
> {noformat}
> Here the rule order would not cause any affect as for any matching rule the
> nodes primary and mixin types would be indexed
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
