You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Andrew Stitcher (JIRA)" <ji...@apache.org> on 2015/09/02 22:15:46 UTC
[jira] [Comment Edited] (QPID-6717) selector can match incorrectly
due to different type for values
[ https://issues.apache.org/jira/browse/QPID-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727947#comment-14727947 ]
Andrew Stitcher edited comment on QPID-6717 at 9/2/15 8:15 PM:
---------------------------------------------------------------
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 '=' expressions 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:
{quote}
X in ('a', 'b', 'c')
{quote}
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.
was (Author: astitcher):
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