[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
---------------------------------
Attachment: QueryNodeFactory_2.patch
I like the patch. Just one thought:
I would prefer removing all those methods that have no factory in their
parameter list (like QueryTreeBuilder.createQueryTree() and
QueryParser.parse()). Instead I would like to remove DEFAULT_QUERY_NODE_FACTORY
from XPathQueryBuilder and JCRSQLQueryBuilder and instantiate QueryImpl in
SearchIndex.createExecutableQuery() with the default query ... well maybe I
better create a patch. A few lines of code are probably clearer than this text
;)
The patch doesn't compile because of MergingPathQueryNode not being covered by
the factory. But I think if we go the QueryNodeFactory way it should create
MergingPathQueryNode instances as well or MergingPathQueryNode should be
removed. The functionality could probably be replaced by plain methods.
Unfortunately I'm really busy at the moment and have no time to investigate
further. Maybe next week.
Although I'm not sure if you like this approach at all. Maybe you need those
methods without the factory parameter for backwards compatibility?
Another thought is that QueryNodes still have public constructors which means
anyone could instance them. They should probably be package private to force
the use of the factory. Ok then, enough ranting. Back to work ... ;)
> Exclude system index for queries that restrict the result set to nodetypes
> not availble in the "jcr:system" subtree
> -------------------------------------------------------------------------------------------------------------------
>
> Key: JCR-1066
> URL: https://issues.apache.org/jira/browse/JCR-1066
> Project: Jackrabbit
> Issue Type: Improvement
> Components: query
> Reporter: Christoph Kiehl
> Assignee: Christoph Kiehl
> Priority: Minor
> Fix For: 1.4
>
> Attachments: patch.txt, patch_with_extendible_system_nodetypes.txt,
> QueryNodeFactory.patch, QueryNodeFactory_2.patch
>
>
> We already have code that is able to decide whether the system index needs to
> be included in a search or not (see JCR-967). If I execute a query like
> "my:app//element(*, my:doc)" this will only search the workspace index.
> Unfortunately this is slower than "//element(*, my:doc)", since the first
> query can not be optimized as the second. In our case both queries return the
> same result set because we use application specific node types. Even though
> the second query includes the system index it is still faster than the first
> one. But it could be even faster because it doesn't need to search the system
> index because nodes with the application specific node type can't be added to
> the "jcr:system"-tree and are therefore are added never to the system index
> (am I right?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
