[ https://issues.apache.org/jira/browse/JCR-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522529 ]
Ard Schrijvers commented on JCR-1064: ------------------------------------- Added patch again. The problem is that in de SearchIndex in the doInti() the index.getIndexReader().numDocs() is always larger then 0 (this was not true untill recently, because it worked for me before) The problem is, that in MultiIndex, when if (indexNames.size() == 0) { , a persistent index is created. The lucene Docs that are added then do not use the nodeIndexer, and thus, the FieldNames.PROPERTIES_SET does not occur, and numDocs > 0, so always old index format style. I can add in MultiIndex a instance variable and a getter, that is boolean created; that I can call from IndexSearcher In doInit(), I get 1) FieldNames.PROPERTIES_SET exists, or 2) numDocs() == 0 or, 3) index.getNewlyCreated() I do not see how it can be done otherwise, because I need to know wether for the particular workspace, a persistent index is created for the first time....I do not really like the dependencies on other code for the backwards compatibility though. WDOT? > 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.