see on GitHub

Data Subscriptions : Creation API Overview



Create and CreateAsync overloads summary

Subscription creation is accessible through DocumentStore's Subscriptions Property, of type DocumentSubscriptions:

string Create(SubscriptionCreationOptions options, string database = null);
string Create<T>(Expression<Func<T, bool>> predicate = null, SubscriptionCreationOptions options = null, string database = null);
string Create<T>(SubscriptionCreationOptions<T> options, string database = null);

Task<string> CreateAsync(SubscriptionCreationOptions options, string database = null, CancellationToken token = default);
Task<string> CreateAsync<T>(Expression<Func<T, bool>> predicate = null, SubscriptionCreationOptions options = null, string database = null, CancellationToken token = default);
Task<string> CreateAsync<T>(SubscriptionCreationOptions<T> options, string database = null, CancellationToken token = default);

Parameters
predicate Expression<Func<T, bool>> Predicate that returns a boolean, describing filter of the subscription documents
options SubscriptionCreationOptions<T> Contains subscription creation options
database string Name of database to create a data subscription. If null, default database configured in DocumentStore will be used.
token CancellationToken Cancellation token used in order to halt the worker operation.
Return value
string Created data subscription name. If Name was provided in SubscriptionCreationOptions, it will be returned, otherwise, a unique name will be generated by server.

SubscriptionCreationOptions

Non generic version of the class, relies on user's full knowledge of the RQL query structure

Member Type Description
Name string 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 string Required. RQL query that describes the subscription. That RQL comes with additional support to javascript clause inside the 'Where' statement and special semantics for subscriptions on documents revisions.
ChangeVector string Allows to define a change vector, from which the subscription will start processing. It might be useful for ad-hoc processes that need to process only recent changes in data, for that specific use, the field may receive a special value: "LastDocument", that will take the latest change vector in the machine.
MentorNode string Allows to define a specific node in the cluster that we want to treat the subscription. That's useful in cases when one server is preffered over other, either because of stronger hardware or closer geographic proximity to clients etc.

SubscriptionCreationOptions<T>

An RQL statement will be built based on the fields.

Member Type Description
<T> type Type of the object, from which the collection will be derived.
Name string User defined name of the subscription: allows to have a human readable identification of a subscription. The name must be unique in the database.
Filter Expression<Func<T, bool>> Lambda describing filter logic for the subscription. Will be translated to a javascript function.
Projection Expression<Func<T, object>> Lambda describing the projection of returned documents. Will be translated to a javascript function
ChangeVector string Allows to define a change vector, from which the subscription will start processing. It might be useful for ad-hoc processes that need to process only recent changes in data, for that specific use, the field may receive a special value: "LastDocument", that will take the latest change vector in the machine.
MentorNode string Allows to define a specific node in the cluster that we want to treat the subscription. That's useful in cases when one server is preffered over other, either because of stronger hardware or closer geographic proximity to clients etc.

Subscription query

All subscriptions, are eventually translated to an RQL-like statement. These statements has four parts:

  • Functions definition part, like in ordinary RQL. Those functions can contain any javascript code, and also supports load and include 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 the regular RQL syntax, except the geo-spatial functions, which not supported by subscriptions. In addition to that, the subscription's where statement can contain defined function calls, allowing performing complex filtering logic.

  • 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.

Syntax limitations

Although subscription's query syntax is RQL-like there are keywords that are not supported:
* Distinct
* index (query an index)
* OrderBy
* GroupBy
* Array
* Sum
* Min
* Max
* Avg
* Update
* Count
* Lucene
* moreLikeThis
* spatial.within
* spatial.contains
* spatial.disjoint
* spatial.intersects
* spatial.circle
* spatial.wkt
* spatial.point

Revisions

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: new SubscriptionCreationOptions<Revision<Order>>()
* For RQL syntax, the (Revisions = true) statement should be concatenated to the collection to be queries. Ex: From orders(Revisions = true) as o