[
https://issues.apache.org/jira/browse/SLING-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-7303:
--------------------------------
Description:
The method named above iterates over the values returned from the row using
{{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of
oak into account. To name just a few:
1) Selectors: Querying with selector like {{select p.\[jcr:score] from
\[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score
because the actual score is stored in {{p.jcr:score}} and the fallback is [an
open
todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
2) Advanced query functionalities: Queries containing for example rep:facet()
dobn't take those into account at all, as the colNames are not iterated, only
the values which only expose stored fields. See the following for all the
cases:
[LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
Along with this bug the unit tests for a couple of scenarios should be added to
cover what BasicQueryLanguageProvider is doing.
was:
The method named above iterates over the values returned from the row using
{{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of
oak into account. To name just a few:
1) Selectors: Querying with selector like {{select p.\[jcr:score] from
\[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score
because the actual score is stored in {{p.jcr:score}} and the fallback is [an
open
todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
2) Advanced query functionalities: Queries containing for example rep:facet()
are not taken into account at all, as the colNames are not iterated, only the
values which only expose stored fields. See the following for all the cases:
[LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
Along with this bug the unit tests for a couple of scenarios should be added to
cover what BasicQueryLanguageProvider is doing.
> BasicQueryLanguageProvider#queryResources does not return all selected fields
> -----------------------------------------------------------------------------
>
> Key: SLING-7303
> URL: https://issues.apache.org/jira/browse/SLING-7303
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: JCR Resource 2.9.2, JCR Resource 3.0.8
> Reporter: Dirk Rudolph
>
> The method named above iterates over the values returned from the row using
> {{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of
> oak into account. To name just a few:
> 1) Selectors: Querying with selector like {{select p.\[jcr:score] from
> \[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score
> because the actual score is stored in {{p.jcr:score}} and the fallback is [an
> open
> todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
> 2) Advanced query functionalities: Queries containing for example rep:facet()
> dobn't take those into account at all, as the colNames are not iterated, only
> the values which only expose stored fields. See the following for all the
> cases:
> [LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
> Along with this bug the unit tests for a couple of scenarios should be added
> to cover what BasicQueryLanguageProvider is doing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
