qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stitcher (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6717) selector can match incorrectly due to different type for values
Date Wed, 02 Sep 2015 20:13:46 GMT

    [ https://issues.apache.org/jira/browse/QPID-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727947#comment-14727947
] 

Andrew Stitcher commented on QPID-6717:
---------------------------------------

I don't think so: the standard you quoted has unlike types compare to false always. As it
explains that the in expression is equivalent to '=' expressions chained with or it seems
to me that you are supposed to treat it as syntactic sugar for this so it is the lower level
'=' expression which count. So as 1 always compares to false against every element of the
set it is indeed not in it.

The semantic you are thinking of is where 1 would be "unknown". Say:

X in ('a', 'b', 'c') where X is undefined (and indeed there is now a test for this case).

The standard does indeed only allow strings in the IN expression, but the qpid Java broker
extended that so I did too. I think there are some other extensions as well, but I don't remember
exactly what they are now.

> selector can match incorrectly due to different type for values
> ---------------------------------------------------------------
>
>                 Key: QPID-6717
>                 URL: https://issues.apache.org/jira/browse/QPID-6717
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Broker
>    Affects Versions: qpid-cpp-0.34
>            Reporter: Gordon Sim
>            Assignee: Andrew Stitcher
>            Priority: Minor
>             Fix For: qpid-cpp-next
>
>
> E.g. a selector "x BETWEEN 1 AND 10" would match for a value of x="foo", because of the
way the logic is implemented for the between expression, or a selector "x NOT IN ('a', 'b',
'c')" would match where x=1, though it should not due to the type mismatch.
> From JMS spec: "Only like type values can be compared. One exception is that it is valid
to compare exact numeric values and approximate numeric values"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message