INPUT_OBJECT

Expression

Filter Expressions

A filter expression restricts the results of a paging request to certain criteria.

Composition of a filter expression

A filter starts with an expression with the fields and, or, not and expression:

filter: {
  and: [ Expression ]
  or: [ Expression ]
  not: { Expression }
  expression: String
}

Composition rules

Exactly one of the fields and, or, not and expression must be set
The boolean and / or fields require an array of expressions with at least two subexpressions
The not field requires an expression
The expression field requires an expression string like id = 4

Expression strings

An expression string is build with operand(s) and an operator:

left-hand-side unary-operator

left-hand-side binary-operator right-hand-side

The left hand side operand

The left hand side of an expression string must be a valid feature path that starts from the requested type. That means that all features of the requested type can be used as the entry point of a feature path. Type conversion is possible by adding a node starting with the keyword 'on' followed by name of the new type in brackets.

Let's assume the paged type is ORDER. Then the following feature paths are valid:

id
confirmations.id
createdFor.account.name
asset.on(FOREX).transactionType
on(MARKETPLACEORDER).tradedAt.id

Special symbol treatment

Symbols can be queried in a simplified way. It is possible to replace the following query:

and: [
  { expression: "path.to.symbols.identifier = 'identifier literal'" }
  { expression: "path.to.symbols.symbolType.name = 'Some Symbol Type Name'" }
]

with:

{ expression: "path.to.symbols.Some Symbol Type Name = 'identifier literal'" }

NOTE 1: When using the simplified expression, a SymbolType name might clash with one or more operators, e.g "path.to.symbols.a symbols type name that barely exists in the real world = 'it might be'". In this case the expression parser will resolve 'exists' as the operator and then complain that 'exists' is unary and has no right-hand side. To be able to use these SymbolType names the name can be url encoded like "path.to.symbols.a%20symbols%20type%20name%20that%20barely%20exists%20in%20the%20real%20world" = 'it might be'. Using the url encoding will prevent the expression parser from recognizing 'exists' and 'in' in the SymbolType name as an operator.

NOTE 2: Every operator that works for strings can be used:

{ expression: "path.to.symbols.Some_Symbol_Type_Name like '%identifier literal%'" }

{ expression: "path.to.symbols.Some_Symbol_Type_Name in ['literal 1', 'literal 2']" }

The right hand side operand

Depending on the left hand side type and the operator the right hand side can be one of the following types: number, string, array or another feature path that points to a feature of the same type:

Strings are enclosed by ':

'Hello World'

A single quote within a string can be escaped with a further single quote:

'Anna''s investment'

Arrays are enclosed by [ and ] and elements are separated by ,:

[1, 2, 3, 4]
['Hello', 'World']

Unary operators

exists test whether a feature has a value or not
```
confirmations.tradeDate exists
```
today test whether a date is today
```
confirmations.tradeDate today
```
not-today test whether a date is not today
```
confirmations.tradeDate not-today
```
yesterday test if a date is yesterday
```
confirmations.tradeDate yesterday
```

Binary operators

= test for equality
```
id = 233
```
!= test for inequality
```
id != 233
```
< test if the left hand side is less than the right hand side
```
id < 233
```
<= test if the left hand side is less or equal than the right hand side
```
id <= 233
```
> test if the left hand side is greater than the right hand side
```
id > 233
```
>= test if the left hand side is greater or equal than the right hand side
```
id >= 233
```
in test if the left hand side is within a list of elements
```
id in [12, 34, 56]
```
not-in test if the left hand side is not within a list of elements
```
id not-in [12, 34, 56]
```
contains-element test if the left hand side contains a certain element. Applies only if the left hand side is a many feature.
```
confirmations contains-element 65575
```
contains test if the left hand side contains a string. Applies only if the left hand side is a text feature.
```
confirmations.comment contains 'hello world'
```
like: test if the left hand side matches a string with wildcards. The wildcard character is %. Applies only if the left hand side is a text feature.
```
confirmations.comment like '%hello%world%'
```
not-like: test if the left hand side does not match a string with wildcards. The wildcard character is %. Applies only if the left hand side is a text feature.
```
confirmations.comment not-like '%hello%world%'
```

Special date expressions

A special syntax for referencing relative dates in the past or in the future exists. The following expressions are possible:

now + <n> days references a date n days in the future from now

confirmations.tradeDate > now + 10 days

now + <n> business days references a date n business days in the future from now

confirmations.tradeDate > now + 10 business days

now - <n> days references a date n days in the past

confirmations.tradeDate > now - 10 business days

now - <n> business days references a date n business days in the past

confirmations.tradeDate > now - 10 business days

A valid filter expression example

filter: {
  or: [  
    { expression: "id = 60000" }
    { expression: "id = 60001" }
    { and: [      
      { expression: "id >= 70000" }
      { expression: "id <= 80000" }
      { not: 
        { expression: "id = 75000" }
      } ]       
      { expression: "confirmations.tradeDate not-today" }
      { expression: "confirmations.tradeDate > now - 30 days" }
      { expression: "confirmations.tradeDate > confirmations.valutaDate" }
    }    
    { expression: "confirmations.comment contains 'hello world'" }
    { expression: "confirmations contains-element 75699" }
  ]
}

GraphQL Schema definition

input Expression {
and: [Expression]
or: [Expression]
expression: String
not: Expression
}