You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Christoph Kiehl (JIRA)" <ji...@apache.org> on 2007/08/16 17:37:30 UTC

[jira] Created: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

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


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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Kiehl updated JCR-1066:
---------------------------------

    Attachment: patch.txt

Added a corrected patch which incorporates the suggested changes. You were absolutely right. I used Section 6.7.22.1 of the JCR 1.0 spec to verify your additions.

> 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
>
>
> 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.


[jira] Commented: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520537 ] 

Marcel Reutegger commented on JCR-1066:
---------------------------------------

> 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?).

Yes, I think that's correct.

The list VALID_SYSTEM_INDEX_NODE_TYPE_NAMES is missing some values:
- intermediate node in the version history tree are of type: rep:versionStorage
- the node /jcr:system is of type: rep:system (not sure if this one needs to be added)
- also all supertypes of the ones already in the list need to be added. for sure nt:base and mix:referenceable. I'm not 100% sure if there are more.
- /jcr:system/jcr:nodeTypes if of type: rep:nodeTypes

> 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
>
>
> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Reutegger updated JCR-1066:
----------------------------------

    Attachment: QueryNodeFactory.patch

I like the idea of a QueryNodeFactory.

What do you think about the patch?

> 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
>
>
> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Kiehl updated JCR-1066:
---------------------------------

    Attachment: patch.txt

This is an initial patch. I'm not fully satisfied with it because PathQueryNode shouldn't know about NodeTypeQueryNode or node types. Maybe someone has a better idea how to implement this?

> 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
>
>
> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated JCR-1066:
-------------------------------

    Component/s: jackrabbit-core

> 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: jackrabbit-core, 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Kiehl updated JCR-1066:
---------------------------------

    Attachment: patch_with_extendible_system_nodetypes.txt

I'm not really happy with all those solutions. I'm still not sure which part of the core should be responsible for deciding which node types are system tree node types. But I think until now the best solution was to let SearchIndex be responsible for that. What I dislike with that approach is that every QueryNode now knows about the jcr system tree node types. Maybe it would be better to have a QueryNodeFactory which could return a PathQueryNode which already knows about the jcr system tree node types?
Anyway - I attached a patch implementing the proposed changes.

> 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
>
>
> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Kiehl updated JCR-1066:
---------------------------------

    Attachment:     (was: patch.txt)

> 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
>
>
> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Kiehl updated JCR-1066:
---------------------------------

    Attachment:     (was: patch.txt)

> 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
>
>
> 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.


[jira] Commented: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521417 ] 

Marcel Reutegger commented on JCR-1066:
---------------------------------------

There's another potential issue. I know of at least one implementation that customizes jackrabbit and uses more than the listed node types under /jcr:system. We should try to make the list customizable.

We could move the list to the SearchIndex class and add a parameter to the method QueryNode.needsSystemTree(). We'd then have: 

public abstract boolean needsSystemTree(Set jcrSystemNodeTypes);

where jcrSystemNodeTypes is a Set of QNames.

> 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
>
>
> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Kiehl updated JCR-1066:
---------------------------------

    Attachment: patch.txt

rep:system was still missing

> 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
>
>
> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Kiehl updated JCR-1066:
---------------------------------

    Attachment:     (was: patch.txt)

> 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
>
>
> 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.


[jira] Resolved: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Reutegger resolved JCR-1066.
-----------------------------------

    Resolution: Fixed

Applied Christoph's patch with minor changes:
- Changed all QueryNode constructors to protected
- Removed unused constructors

Committed in revision: 570095

> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Kiehl updated JCR-1066:
---------------------------------

    Attachment: patch.txt

The first patch was incomplete

> 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
>
>
> 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.


[jira] Updated: (JCR-1066) Exclude system index for queries that restrict the result set to nodetypes not availble in the "jcr:system" subtree

Posted by "Christoph Kiehl (JIRA)" <ji...@apache.org>.
     [ 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.