[jira] [Comment Edited] (OAK-6831) Nodetype index support in Lucene Index

["Chetan Mehrotra (JIRA)" <ji...@apache.org>]

    [ 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)