Description of problem: when escaping like statement, '%' and '_' cannot be used as escape characters for their respecitve wildcards: '%%' or '__', in that way both characted are treated as escape and pattern is not recognized correctly Version-Release number of selected component (if applicable): qpid-cpp-server-0.22-37 How reproducible: 100% Steps to Reproduce: 1. ./qc2_spout --log-msgs dict -P a=prefixtest% "q;{create:always}" 2. ./qc2_drain --log-msgs dict "q;{link:{selector:\"a LIKE '%test%%' ESCAPE '%'\"}}" Actual results: [1] {'redelivered': False, 'reply_to': None, 'subject': None, 'content_type': None, 'id': None, 'user_id': None, 'correlation_id': None, 'priority': 0, 'durable': False, 'ttl': 0.000000e+00, 'size': None, 'properties': {'a': 'prefixtest%', 'spout-id': '3f92a615-82e2-49e9-913b-09c4f08c0205:0', 'x-amqp-0-10.routing-key': 'q'}, 'content': None} [2] Expected results: receiver receives that message Additional info: the same result for '__' case # qpid log 2014-04-23 10:07:13 [Model] debug Create connection. user:anonymous rhost:qpid.127.0.0.1:5672-127.0.0.1:47222 2014-04-23 10:07:13 [Broker] debug anonymous.07656cc8-2a7f-4f72-b288-2a4e7d9b4221: attached on broker. 2014-04-23 10:07:13 [Broker] debug anonymous.07656cc8-2a7f-4f72-b288-2a4e7d9b4221: ready to send, activating output. 2014-04-23 10:07:13 [Broker] debug Selector parsed[a LIKE '%test%%' ESCAPE '%'] into: I:a REGEX_MATCH '^test$' 2014-04-23 10:07:13 [Model] debug Create subscription. queue:q destination:q user:anonymous rhost:qpid.127.0.0.1:5672-127.0.0.1:47222 exclusive:F 2014-04-23 10:07:13 [Broker] debug next() called for invalid cursor, index started at 0 (of 1) 2014-04-23 10:07:13 [Broker] debug in next(), cursor set to 1 2014-04-23 10:07:13 [Broker] debug in next(), returning message at 1 2014-04-23 10:07:13 [Broker] debug Selector identifier: a->STRING:'prefixtest%' 2014-04-23 10:07:13 [Broker] debug Consumer doesn't want message from 'q' 2014-04-23 10:07:13 [Broker] debug next() called for cursor at 1, index set to 1 (of 1) 2014-04-23 10:07:13 [Broker] debug no message to return from next 2014-04-23 10:07:13 [Broker] debug No messages to dispatch on queue 'q' 2014-04-23 10:07:13 [Broker] debug next() called for cursor at 1, index set to 1 (of 1) 2014-04-23 10:07:13 [Broker] debug no message to return from next 2014-04-23 10:07:13 [Broker] debug No messages to dispatch on queue 'q' 2014-04-23 10:07:13 [Model] debug Delete subscription. destination:q user:anonymous rhost:qpid.127.0.0.1:5672-127.0.0.1:47222 2014-04-23 10:07:13 [Broker] debug anonymous.07656cc8-2a7f-4f72-b288-2a4e7d9b4221: detached on broker. 2014-04-23 10:07:13 [Model] debug Delete connection. user:anonymous rhost:qpid.127.0.0.1:5672-127.0.0.1:47222
I think the bug here is that the escape character is not allowed to be '%' or '_' and if it is this should cause an error. To see why this is the case notice that if you did allow either '%' or '_' to be the escape character there would be no way to indicate that you actually meant the wildcard character and not the escaped version.
Andrew, maybe you see something in there that I don't. Because for me is clearly distinguishable which is wildcard and which is escaped. SQL does it, python string formatting does it. I'd just followed the SQL-92 syntax documentation on this.
Zdenek, perhaps you could point me at that documentation then. (how would %%% escape % be parsed?) In the meantime I have posted a fix to qpid trunk which disallows the % and _ characters as wildcards - it is certainly never necessary to use them this way.
[1] http://docs.oracle.com/cd/B12037_01/server.101/b10759/conditions016.htm I've red it again, and it's my bad, there is an exception for %, _. You were right. So I change the name to match the real problem (Comment 1). Thank you. But I still claim, that it's parsable. '%%%' would be parsed with priority from left, thus '%%' as literal percent and rest as the wildcard. But on the other hand I see it's useless.
This deferred bug is covered by automated test and it already is in POST status, please consider returning it to 3.0.0, it will be much less effort to verify it than removing and verifying it's not present.
Tested on RHEL 6.5 i686 and x86_64 with following packages: qpid-cpp-client-0.22-43 qpid-cpp-client-devel-0.22-43 qpid-cpp-client-devel-docs-0.22-43 qpid-cpp-server-0.22-43 qpid-cpp-server-devel-0.22-43 qpid-cpp-server-linearstore-0.22-43 qpid-cpp-server-xml-0.22-43 Works as expected.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1296.html