Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <3959289.1188899818611.JavaMail.jira@brutus>
Date: Tue, 4 Sep 2007 02:56:58 -0700 (PDT)
From: "Ard Schrijvers (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1064) Optimize queries that check for the
 existence of a property
In-Reply-To: <15082026.1187185770563.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

> I just found another issue with the MultiIndex. The recovery code also runs inside the constructor and the redo log is applied it may 
> happen that a node is indexed, which in turn needs to know the IndexFormatVersion.

Do you have some preferred place to fix the problem with the redo log? Suppose you don't want the check for index format style in the Recovery.run() right? 

If you can give me your preference, I might be able to complete the patch/issue/improvement....\o/\o/

> 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-2.patch, JCR-1064-2.patch, JCR-1064-2.patch, JCR-1064-2.patch, JCR-1064-DEPR.patch
>
>
> //*[@mytext] 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.