[ 
https://issues.apache.org/jira/browse/JCR-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522547
 ] 

Ard Schrijvers commented on JCR-1064:
-------------------------------------

By the way: Are you really sure that it matters wether the parent query handler 
is in the new format? AFAICS, it doesn't matter wether one index, even the 
parent one, is in format old or new. 

All tests run also without problems.  When in doInit() I add the test

if (context.getParentHandler() instanceof SearchIndex){
            SearchIndex parentQueryHandler = 
(SearchIndex)(context.getParentHandler());
            if(parentQueryHandler.getIndexFormatVersion() != 
this.getIndexFormatVersion()){
                /*
                 * parentHandler is not allowed to be in different format. 
Fallback to
                 * old style
                 */ 
                log.warn("parentQueryHandler is in different format. Fallback 
to old format style");
                setIndexFormatVersion(IndexFormatVersion.V1);
            }
        }

and I delete the parent index (repository/index/*) and I delete the workspace 
index,. everything run in the new index format. Though, the parent index is 
created differently then the workspace indices, so in the NodeIndexer, 

if(indexFormatVersion == IndexFormatVersion.V2) {
        addPropertyName(doc,propState.getName());
{

does not work because it is null for the parent query handler. Hence, after 
restart, the system will fallback into old format style, because the parent 
index format style is old!

So, I can add to the NodeIndexer something like:

if(indexFormatVersion == null || indexFormatVersion == IndexFormatVersion.V2) {
                        addPropertyName(doc,propState.getName());
}

this forces that the parent query handler indexes according new style. But, I 
just think the backwards compatible becomes a little hacky. 

I'll add a patch, in without the parent query handler check. If is turns out 
that it is needed, we can add it. WDYT?



> Optimize queries that check for the existence of a property
> -----------------------------------------------------------
>
>                 Key: JCR-1064
>                 URL: https://issues.apache.org/jira/browse/JCR-1064
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: indexing
>    Affects Versions: 1.3.1
>            Reporter: Ard Schrijvers
>            Priority: Minor
>             Fix For: 1.4
>
>         Attachments: JCR-1064-DEPR.patch
>
>
> //[EMAIL PROTECTED] is transformed into the 
> org.apache.jackrabbit.core.query.lucene.MatchAllQuery, that through the 
> MatchAllWeight uses the MatchAllScorer.  The calculateDocFilter() in 
> MatchAllScorer  does not scale and becomes slow for growing number of nodes. 
> Solution: lucene documents will get a new Field:
> public static final String PROPERTIES_SET = "_:PROPERTIES_SET".intern();
> that holds the available properties of this document. 
> NOTE: Lucene indices build without this performance improvement should still 
> work and fall back to the original implementation

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to