RTI Connext Modern C++ API Version 7.2.0
Queries and Filters Syntax

Syntax for DDS Queries and Filters

A subset of the WHERE clause in SQL is used in several parts of the specification:

Those expressions may use a subset of SQL, extended with the possibility to use program variables in the SQL expression. The allowed SQL expressions are defined with the BNF-grammar below.

The following notational conventions are made:

SQL grammar in BNF

FilterExpression ::= Condition
Condition   ::= Predicate
            |   Condition 'AND' Condition
            |   Condition 'OR' Condition
            |   'NOT' Condition
            |   '(' Condition ')'
Predicate   ::= ComparisonPredicate
            |   BetweenPredicate
ComparisonPredicate ::= ComparisonTerm RelOp ComparisonTerm
ComparisonTerm      ::= FieldIdentifier
                    | Parameter
BetweenPredicate    ::= FieldIdentifier 'BETWEEN' Range
                    |   FieldIdentifier 'NOT BETWEEN' Range
FieldIdentifier      ::= FIELDNAME
                    | IDENTIFIER
RelOp     ::= '=' | '>' | '>=' | '<' | '<=' | '<>' | 'LIKE' | 'MATCH'
Range     ::= Parameter 'AND' Parameter
Parameter ::= INTEGERVALUE
          |   CHARVALUE
          |   FLOATVALUE
          |   STRING
          |   ENUMERATEDVALUE
          |   BOOLEANVALUE
          |   NULLVALUE
          |   PARAMETER

Token expression

The syntax and meaning of the tokens used in the SQL grammar is described as follows:

Formal notation:

      IDENTIFIER: LETTER (PART_LETTER)*
      where LETTER: [ "A"-"Z","_","a"-"z" ]
            PART_LETTER: [ "A"-"Z","_","a"-"z","0"-"9" ]
      

Formal notation:

      FIELDNAME: FieldNamePart ( "." FieldNamePart )*
      where FieldNamePart : IDENTIFIER ( "[" Index "]" )*
            Index> : (["0"-"9"])+
                   | ["0x","0X"](["0"-"9", "A"-"F", "a"-"f"])+
      

Primitive IDL types referenced by FIELDNAME are treated as different types in Predicate according to the following table:

Predicate Data Type IDL Type
BOOLEANVALUE boolean
INTEGERVALUE octet, (unsigned) short, (unsigned) long, (unsigned) long long
FLOATVALUE float, double
CHARVALUE char, wchar
STRING string, wstring
ENUMERATEDVALUE enum

Formal notation:

       TOPICNAME : IDENTIFIER
       

Formal notation:

       INTEGERVALUE : (["+","-"])? (["0"-"9"])+ [("L","l")]?
                    | (["+","-"])? ["0x","0X"](["0"-"9", "A"-"F", "a"-"f"])+ [("L","l")]?
       

Formal notation:

       CHARVALUE : "'" (~["'"])? "'"
       

Formal notation:

      FLOATVALUE : (["+","-"])? (["0"-"9"])* (".")? (["0"-"9"])+ (EXPONENT)?
      where EXPONENT: ["e","E"] (["+","-"])? (["0"-"9"])+
      

Formal notation:

      STRING : "'" (~["'"])* "'"
      

Formal notation:

      ENUMERATEDVALUE : "'" ["A" - "Z", "a" - "z"] ["A" - "Z", "a" - "z", "_", "0" - "9"]* "'"
      

Formal notation (case insensitive):

      BOOLEANVALUE : ["TRUE","FALSE"]
      

Formal notation (case insensitive):

      NULLVALUE : "null"
      

Formal notation:

      PARAMETER : "%" (["0"-"9"])+
      

String Parameters

Strings used as parameter values must contain the enclosing quotation marks (') within the parameter value, and not place the quotation marks within the expression statement. For example, the following expression is legal:

" symbol MATCH %0 " with parameter 0 = " 'IBM' "

whereas the following expression will not compile:

" symbol MATCH '%0' " with parameter 0 = " IBM "

Type compatability in Predicate

Only certain combination of type comparisons are valid in Predicate. The following table marked all the compatible pairs with 'YES':

BOOLEANVALUE INTEGERVALUE FLOATVALUE CHARVALUE STRING ENUMERATEDVALUE
BOOLEAN YES
INTEGERVALUE YES YES
FLOATVALUE YES YES
CHARVALUE YES YES YES
STRING YES YES(*1) YES
ENUMERATEDVALUE YES YES(*2) YES(*2) YES(*3)

SQL Extension: Regular Expression Matching

The relational operator MATCH may only be used with string fields. The right-hand operator is a string pattern. A string pattern specifies a template that the left-hand field value must match. The characters ,/\?*[]-^!% have special meanings unless they are escaped by the escape character "\". MATCH is case-sensitive. The pattern allows limited "wild card" matching under the following rules: <TABLE> <TR> <TD><b>Character</b></TD> <TD><b>Meaning</b></TD></TR> <TR> <TD><b>,</b></TD> <TD>"," separates a list of alternate patterns. The field string is matched if it matches one or more of the patterns.</TD> </TR> <TR> <TD><b>/</b></TD> <TD>"/" in the pattern string matches a / in the field string. This character is used to separate a sequence of mandatory substrings.</TD> </TR> <TR> <TD><b>?</b></TD> <TD>"?" in the pattern string matches any single <i>non-special</i> characters in the field string.</TD> </TR> <TR> <TD><b>*</b></TD> <TD>"*" in the pattern string matches 0 or more <i>non-special</i> characters in field string.</TD> </TR> <TR> <TD><b>[<i>charlist</i>]</b></TD> <TD>Matches any one of the characters from the list of characters in <i>charlist</i>.</TD> </TR> <TR> <TD><b>[<i>s</i>-<i>e</i>]</b></TD> <TD>Matches any character any character from <i>s</i> to <i>e</i>, inclusive.</TD> </TR> <TR> <TD><b>%</b></TD> <TD>"%" is used to designate filter expressions parameters.</TD> </TR> <TR> <TD><b>[!<i>charlist</i>] or [^<i>charlist</i>]</b></TD> <TD>Matches any characters not in <i>charlist</i> (not supported).</TD> </TR> <TR> <TD><b>[!<i>s</i>-<i>e</i>] or [^<i>s</i>-<i>e</i>]</b></TD> <TD>Matches any characters not in the interval [s-e] (not supported).</TD> </TR> <TR> <TD><b>\\</b></TD> <TD>Escape character for special characters.</TD> </TR> </TABLE> The syntax is similar to the POSIX fnmatch syntax (1003.2-1992 section B.6). The MATCH syntax is also similar to the 'subject' strings of TIBCO Rendezvous. <b>Note:</b> To use special characters as regular characters in regular expressions, you must escape them using the character "". For example, 'A[' is considered a malformed expression and the result is undefined.

Character Encoding

The default encoding for IDL strings is UTF-8. RTI Connext offers ISO 8859-1 as an alternative encoding for IDL strings.

In order to configure ISO 8859-1 as the encoding for filtering of IDL strings, you can set the DomainParticipant property dds.domain_participant.filtering_character_encoding to ISO-8859:

The possible values for dds.domain_participant.filtering_character_encoding are:

Unicode Normalization

Unicode supports multiple ways to encode some characters, most notably accented characters. A composed character in Unicode can often have a number of different ways of representing the character. For example:

The lexical comparison of the two characters above will return false. In order to do the correct comparison the characters need to be normalized, that is, reduced to the same character composition.

When the character encoding for filtering of IDL strings is UTF-8, the Unicode normalization behavior can be controlled using a DomainParticipant property called dds.domain_participant.filtering_unicode_normalization.

The possible values of the normalization property are:

Because normalization may affect performance, and it is enabled by default, the property allows disabling the normalization process per DomainParticipant using the value OFF. However, you should be aware that doing this may lead to unexpected behavior.

Examples

Assuming Topic "Location" has as an associated type a structure with fields "flight_id, x, y, z", and Topic "FlightPlan" has as fields "flight_id, source, destination". The following are examples of using these expressions.

Example of a filter_expression (for dds::topic::ContentFilteredTopic) or a query_expression (for dds::sub::cond::QueryCondition):

Examples of a filter_expression using MATCH (for dds::topic::ContentFilteredTopic) operator: