Skip to content

Support AMQP SQL Filter Expressions #14184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 18 commits into
base: main
Choose a base branch
from
Draft

Support AMQP SQL Filter Expressions #14184

wants to merge 18 commits into from

Conversation

ansd
Copy link
Member

@ansd ansd commented Jul 3, 2025

Instead of the JMS message selector syntax as introduced in #14110, support a subset of the AMQP SQL Filter Expressions syntax as defined in AMQP Filter Expressions Version 1.0 Committee Specification Draft 01.

@ansd ansd added this to the 4.2.0 milestone Jul 3, 2025
@ansd ansd self-assigned this Jul 3, 2025
@mergify mergify bot added the make label Jul 3, 2025
@ansd ansd force-pushed the amqp-sql branch 8 times, most recently from 614e14f to b1a052e Compare July 9, 2025 10:38
ansd added 7 commits July 14, 2025 09:29
Instead of the JMS message selector syntax, support a subset of the
AMQP SQL Filter Expressions syntax as defined in
[AMQP Filter Expressions Version 1.0 Committee Specification Draft 01](https://docs.oasis-open.org/amqp/filtex/v1.0/csd01/filtex-v1.0-csd01.html#_Toc67929276).

This commit changes the descriptors.
"A partner MAY indicate support and yet it MAY still refuse to accept
certain filters or combination of filters for some scenarios."
[NOT] BETWEEN operator is not supported in AMQP SQL
The spec is underspecified in what should happen if the left hand side
is a float. This commit decides that the result is undefined (unknown).

The spec is also underspecified in what should happen if either the left
hand side or the right hand side is negative. This commit decides to use
the behaviour of Erlang `rem`.
ansd added 5 commits July 14, 2025 10:02
AMQP SQL spec:
"The left operand is of greater value than the right operand if:
... both operands are of type string or of type symbol (any combination is permitted) and the
lexicographical rank of the left operand is greater than the lexicographical rank of the right operand."

In contrast, in JMS:
"String [...] comparison is restricted to = and <>."
Allow only upper case predefined selector literals and operator names.

The JMS spec states:
> Predefined selector literals and operator names are written here in upper case; however, they are case insensitive.

However, the AMQP SQL spec does not include such a statement.
The EBNF notation with single quotes ('AND') typically implies exact literal matching.
This commit follows the AMQP SQL's EBNF notation and therefore disallows
lower case predefined selector literals or operator names.
JMS:
> A string literal is enclosed in single quotes, with an included single quote represented
> by doubled single quote; for example, 'literal' and 'literal''s'.

AMQP SQL
https://docs.oasis-open.org/amqp/filtex/v1.0/csd01/filtex-v1.0-csd01.html#_Toc67929302
> A string constant is a string of arbitrary text consisting of any valid printable Unicode
> characters surrounded by single or double quotation marks. A quotation mark inside the
> string is represented by two consecutive quotation marks.
> string_constant ::= { ‘ | “ } <any> [<any>] { ‘ | “ }
ansd added 2 commits July 14, 2025 11:13
The spec mandates:
> The wildcard matching MUST consume as few characters as possible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant