Create and Update Subscription API
Create subscription
Subscriptions can be created using the create_for_options
and create_for_class
methods.
def create_for_options(self, options: SubscriptionCreationOptions, database: Optional[str] = None) -> str: ...
def create_for_class(
self,
object_type: Type[_T],
options: Optional[SubscriptionCreationOptions] = None,
database: Optional[str] = None,
) -> str: ...
Parameter | Type | Description |
---|---|---|
options | SubscriptionCreationOptions |
Contains subscription creation options |
database (Optional) | [str] |
The name of the database where the subscription task will be created. If None , default database configured in DocumentStore will be used. |
object_type | Type[_T] |
Predicate describing the subscription documents filter |
Return value | Description |
---|---|
str |
Created data subscription name. If the name was provided in SubscriptionCreationOptions , it will be returned. Otherwise, a unique name will be generated by the server. |
SubscriptionCreationOptions
An RQL statement will be built based on the fields.
class SubscriptionCreationOptions:
def __init__(
self,
name: Optional[str] = None,
query: Optional[str] = None,
includes: Optional[Callable[[SubscriptionIncludeBuilder], None]] = None,
change_vector: Optional[str] = None,
mentor_node: Optional[str] = None,
):
self.name = name
self.query = query
self.includes = includes
self.change_vector = change_vector
self.mentor_node = mentor_node
Member | Type | Description |
---|---|---|
name (Optional) | str |
User-defined name of the subscription: allows to have a human readable identification of a subscription. The name must be unique in the database. |
query (Optional) | str |
RQL query that describes the subscription. This RQL comes with additional support to JavaScript functions inside the where clause and special semantics for subscriptions on documents revisions. |
change_vector (Optional) | str |
Allows to define a change vector from which the subscription will start processing. Useful for ad-hoc processes that need to process only recent changes. In such cases, you can set the field to "LastDocument" to start processing from the latest document in the collection. |
mentor_node (Optional) | str |
Allows to define a specific node in the cluster to handle the subscription. Useful when you prefer a specific server due to its stronger hardware, closer geographic proximity to clients, or other reasons. |
includes (Optional) | [Callable[[SubscriptionIncludeBuilder] |
Action with a SubscriptionIncludeBuilder parameter that allows you to define an include clause for the subscription. Methods can be chained to include documents as well as counters. |
Update subscription
Modifies an existing data subscription. These methods are accessible at DocumentStore.Subscriptions
.
def update(self, options: SubscriptionUpdateOptions, database: Optional[str] = None) -> str: ...
Parameter | Type | Description |
---|---|---|
options | SubscriptionUpdateOptions |
A subscription update options object |
database (Optional) | str |
The name of the database where the subscription task will be created. If None , default database configured in DocumentStore will be used. |
Return value | Description |
---|---|
str |
The updated data subscription's name. |
SubscriptionUpdateOptions
Inherits from SubscriptionCreationOptions
and has all the same fields (see above) plus the two additional fields described below:
class SubscriptionUpdateOptions(SubscriptionCreationOptions):
def __init__(
self,
name: Optional[str] = None,
query: Optional[str] = None,
includes: Optional[Callable[[SubscriptionIncludeBuilder], None]] = None,
change_vector: Optional[str] = None,
mentor_node: Optional[str] = None,
key: Optional[int] = None,
create_new: Optional[bool] = None,
): ...
Parameter | Type | Description |
---|---|---|
key (Optional) | int |
Unique server-side ID of the data subscription. key can be used instead of the subscription update options name field, and takes precedence over it. This allows you to change the subscription's name: submit a subscription's ID, and submit a different name in the name field. |
create_new (Optional) | bool |
Determines the behavior when the subscription you wish to update does Not exist.true - a new subscription is created with the provided option parameters.false - an exception will be thrown.Default: false |
Subscription query
All subscriptions are eventually translated to an RQL-like statement. These statements have the following parts:
-
Functions definition part, like in ordinary RQL. Those functions can contain any JavaScript code, and also supports
load
andinclude
operations. -
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 support either RQL like
equality
operations (=
,==
) ,
plain JavaScript expressions or declared function calls, allowing to perform complex filtering logic.
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.
Keywords
Although subscription's query syntax has an RQL-like structure, it supports only the declare
, select
and where
keywords, usage of all other RQL keywords is not supported.
Usage of JavaScript ES5 syntax is supported.
Paths
Paths in subscriptions RQL statements are treated as JavaScript indirections and not like regular RQL paths.
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)
{
if (!!doc.Lines){
return doc.Lines.filter(x=>x.Product == productId).length >0;
}
return false;
}
from Orders as o
where filterLines(o, "products/1-A")