[
https://issues.apache.org/jira/browse/JCR-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523176
]
Ard Schrijvers commented on JCR-1064:
-------------------------------------
> well, that just means that there is no appropriate test
You mean that the tests just happen to work with new and old format by
coincidence? I just really am in the assumption, that a query is done on one
index at the time, and wether this index is in the old or new format does not
matter. Wether the system index is in old format, and the query runs on a
workspace index in new format shouldn't give problems AFAICS. IMO, it is
possible to port the jr impl to the new version while keeping all the indices,
and when adding a new workspace, only this workspace will run in the new
format. But I do not have the overview like you do, so I probably just miss
something :-). I'll stop worrying about it and go for your solution.
> WRT the bootstrapping issue with the index and its format, I will create a
> separate issue and extract the initial index creation from the >MultiIndex
> constructor. See JCR-1093. Once this is solved, you can set the index format
> version before indexing the workspace.
That would be very nice. When you have finished, I'll create a new patch
> that's actually another point that should be changed. There should be a
> default value. I suggest we set it to V1.
Agreed.
I'll wait for JCR-1093 and then create a new patch.
> 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-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.
