You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Vikas Saurabh (JIRA)" <ji...@apache.org> on 2014/08/21 23:12:12 UTC

[jira] [Comment Edited] (OAK-1977) ContentMirrorStoreStrategy should utilize path restriction when available

    [ https://issues.apache.org/jira/browse/OAK-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14105695#comment-14105695 ] 

Vikas Saurabh edited comment on OAK-1977 at 8/21/14 9:11 PM:
-------------------------------------------------------------

[~tmueller], {{OrderedPropertyIndexQueryTest}} is failing because with OAK-1980, ordered indices support sub-root locations too. For that, it creates a {{PrefixCursor}} instance which prepends filter's path to results returned by index. The attached patch also does the same concatenation and hence with OAK-1980+attached patch, the result nodes' paths get filter's path prefixed twice which is then discarded.

OAK-1980 is marked for Oak1.1 as, I believe, it's more of a feature to allow indices to be defined under a sub-tree. OTOH, I believe, this issue is a simple performance improvement which can be taken in 1.0 branch as well.

About fixing the issue, I see following options:
# have {{PathIterator}} to get currently used index's meta node's path so that it can concatenate only relevant portion -- I'm not sure how exactly though :-/ (any pointers?)
# convert PropertyIndex to AdvancedQueryIndex and have same mechanism for prefixing filter path as is being used in OAK-1980 (I think AdvancedQueryIndex is a 1.1 thing and so this would be incompatible with 1.0 branch :()
# take the less general fix and open another issue to generalize it without {{isFilterAware}}/{{shouldDescendDirectly}} (where I hope the less general fix can be applied on 1.0 directly and the general one can be put on 1.1 only)

WDYT?

(cc [~edivad])


was (Author: catholicon):
[~tmueller], {{OrderedPropertyIndexQueryTest}} is failing because with OAK-1980, ordered indices support sub-root locations too. For that, it creates a {{PrefixCursor}} instance which prepends filter's path to results returned by index. The attached patch also does the same concatenation and hence with OAK-1980+attached patch, the result nodes' paths get filter's path prefixed twice which is then discarded.

OAK-1980 is marked for Oak1.1 as, I believe, it's more of a feature to allow indices to be defined under a sub-tree. OTOH, I believe, this issue is a simple performance improvement which can be taken in 1.0 branch as well.

About fixing the issue, I see following options:
# have {{PathIterator}} to get currently used index's meta node's path so that it can concatenate only relevant portion -- I'm not sure how exactly though :-/ (any pointers?)
# take the less general fix and open another issue to generalize it without {{isFilterAware}}/{{shouldDescendDirectly}} (where I hope the less general fix can be applied on 1.0 directly and the general one can be put on 1.1 only)

WDYT?

(cc [~edivad])

> ContentMirrorStoreStrategy should utilize path restriction when available
> -------------------------------------------------------------------------
>
>                 Key: OAK-1977
>                 URL: https://issues.apache.org/jira/browse/OAK-1977
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: query
>    Affects Versions: 1.0.1
>            Reporter: Vikas Saurabh
>            Assignee: Thomas Mueller
>             Fix For: 1.1
>
>         Attachments: 1977-benchmark.patch, 1977-proposed.patch
>
>
> Currently {{ContentStoreMirrorStrategy}} has a mirror of content path under {{:index}}. Yet, while {{query}} (and {{count}}) methods doesn't jump directly into restricted path.
> This would be very useful for {{PropertyIndex}} where the queries can be optimized by supplying a path restriction along with an indexed property restriction (I don't know if queries with references would use paths so much though)



--
This message was sent by Atlassian JIRA
(v6.2#6252)