All subscriptions, are eventually translated to an RQL-like statement. These statements has four parts:
and also supports
From statement, defining the documents source, ex:
from Orders. The from statement can only address collections, therefore, indexes are not supported.
Where statement describing the criteria according to which it will be decided to either
send the documents to the worker or not. Those statements supports either RQL like
equality operations (
The subscriptions RQL does not support any of the known RQL searching keywords.
Select statement, that defines the projection to be performed.
The select statements can contain function calls, allowing complex transformations.
Include statement allowing to define include path in document.
Although subscription's query syntax has an RQL-like structure, it supports only the
where keywords, usage of all other RQL keywords is not supported.
It means that a query that in RQL would look like:
from Orders as o
where o.Lines.Product = "products/1-A"
Will look like that in subscriptions RQL:
declare function filterLines(doc, productId)
return doc.Lines.filter(x=>x.Product == productId).length >0;
from Orders as o
where filterLines(o, "products/1-A")
In order to define a data subscription that uses documents revisions, there first has to be revisions configured for the specific collection.
The subscription should be defined in a special way:
* In case of the generic API, the
SubscriptionCreationOptions<> generic parameter should be of the generic type
Revision<>, while it's generic parameter correlates to the collection to be processed. Ex:
* For RQL syntax, the
(Revisions = true) statement should be concatenated to the collection to be queries. Ex:
From orders(Revisions = true) as o