[
https://issues.apache.org/jira/browse/OAK-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-1171:
---------------------------------------
Description:
A simple xpath query for a string property doesn't work when there is a long
(or other inconvertible) property under the same name anywhere in the
repository.
To reproduce:
* Create a {{LONG}} property: {{/test/@property = 1}}
* Run this query: {{//*\[property = "foo"]}}
This will throw a NumberFormatException at
{{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}} and
fail the query.
Jackrabbit 2 works well here and simply does not include a match for that node
in the result. While I can see that Oak seems to implement the [JCR 2.0
spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
{quote}
If operand1 and operand2 evaluate to values of different property types, the
value of operand2 is converted to the property type of the value of operand1 as
described in §3.6.4 Property Type Conversion. If the type conversion fails, the
query is _invalid_.
{quote}
... I don't think this makes any sense. If conversion does not work, this is
simply not a match, but it must not break the query.
was:
To reproduce:
* Create a {{LONG}} property: {{/test/@property = 1}}
* Run this query: {{//*\[property = "foo"]}}
This will throw a NumberFormatException at
{{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}} and
fail the query.
Jackrabbit 2 works well here and simply does not include a match for that node
in the result. While I can see that Oak seems to implement the [JCR 2.0
spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
{quote}
If operand1 and operand2 evaluate to values of different property types, the
value of operand2 is converted to the property type of the value of operand1 as
described in §3.6.4 Property Type Conversion. If the type conversion fails, the
query is _invalid_.
{quote}
... I don't think this makes any sense. If conversion does not work, this is
simply not a match, but it must not break the query.
> Query fails unexpectedly when property conversion is not possible
> -----------------------------------------------------------------
>
> Key: OAK-1171
> URL: https://issues.apache.org/jira/browse/OAK-1171
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr, query
> Reporter: Alexander Klimetschek
>
> A simple xpath query for a string property doesn't work when there is a long
> (or other inconvertible) property under the same name anywhere in the
> repository.
> To reproduce:
> * Create a {{LONG}} property: {{/test/@property = 1}}
> * Run this query: {{//*\[property = "foo"]}}
> This will throw a NumberFormatException at
> {{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}}
> and fail the query.
> Jackrabbit 2 works well here and simply does not include a match for that
> node in the result. While I can see that Oak seems to implement the [JCR 2.0
> spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
> {quote}
> If operand1 and operand2 evaluate to values of different property types, the
> value of operand2 is converted to the property type of the value of operand1
> as described in §3.6.4 Property Type Conversion. If the type conversion
> fails, the query is _invalid_.
> {quote}
> ... I don't think this makes any sense. If conversion does not work, this is
> simply not a match, but it must not break the query.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
