[
https://issues.apache.org/jira/browse/OAK-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820899#comment-13820899
]
Alexander Klimetschek commented on OAK-1171:
--------------------------------------------
OAK-1076 might be related. It refers to range queries, not the equality
operator, but the issue might be the same.
> 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
>
> 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)
