jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (JCR-2282) SQL2 parser must not infer type for UncastLiteral from static analysis
Date Fri, 28 Aug 2009 07:36:59 GMT

    [ https://issues.apache.org/jira/browse/JCR-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748709#action_12748709
] 

Thomas Mueller edited comment on JCR-2282 at 8/28/09 12:35 AM:
---------------------------------------------------------------

Because of this change the build now fails with

javax.jcr.query.InvalidQueryException: Static value 3.0 cannot be converted to a Long
for the query:
SELECT * FROM [nt:unstructured] AS s WHERE ISCHILDNODE(s, [/testroot]) AND LENGTH(s.prop1)
= 3.0

3.0 used to be parsed as a BigDecimal, and could be converted to a Long.
Now 3.0 is parsed as a String (actually first parsed as a BigDecimal and then converted to
a String by the parser).
Long.parseLong("3.0") fails.

If you want the query to work, you could write:
... AND LENGTH(s.prop1) = CAST(3.0 AS DOUBLE).

I think we should rather change the spec than trying to build a workaround.
It's weird that the parser should read 3.0 to a String, and only as a double if you write
CAST(3.0 AS DOUBLE).

I filed a bug yesterday: https://jsr-283.dev.java.net/issues/show_bug.cgi?id=806

So I suggest to undo my commit, and change the spec instead.

      was (Author: tmueller):
    Because of this change the build now fails with

javax.jcr.query.InvalidQueryException: Static value 3.0 cannot be converted to a Long
for the query:
SELECT * FROM [nt:unstructured] AS s WHERE ISCHILDNODE(s, [/testroot]) AND LENGTH(s.prop1)
= 3.0

3.0 used to be parsed as a BigDecimal, and could be converted to a Long.
Now 3.0 is parsed as a String (actually first parsed as a String and then converted to a String
by the parser).
Long.parseLong("3.0") fails.

If you want the query to work, you could write:
... AND LENGTH(s.prop1) = CAST(3.0 AS DOUBLE).

I think we should rather change the spec than trying to build a workaround.
It's weird that the parser should read 3.0 to a String, and only as a double if you write
CAST(3.0 AS DOUBLE).

I filed a bug yesterday: https://jsr-283.dev.java.net/issues/show_bug.cgi?id=806

So I suggest to undo my commit, and change the spec instead.
  
> SQL2 parser must not infer type for UncastLiteral from static analysis
> ----------------------------------------------------------------------
>
>                 Key: JCR-2282
>                 URL: https://issues.apache.org/jira/browse/JCR-2282
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-tests, jackrabbit-spi-commons
>            Reporter: Marcel Reutegger
>            Priority: Minor
>
> The spec says:
> "An UncastLiteral is always interpreted as a Value of property type STRING. A CastLiteral,
on the other hand, is interpreted as the string form of a Value of the PropertyType indicated."
> There are also two test cases in NodeNameTest that need to be fixed accordingly: testLongLiteral
and testBooleanLiteral

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message