RTI Connext Traditional C++ API  Version 5.2.0
 All Classes Functions Variables Typedefs Enumerations Enumerator Groups Pages
Filter Use Cases

Working with data filters. More...

Working with data filters.

Introduction

RTI Connext supports filtering data either during the exchange from DDSDataWriter to DDSDataReader, or after the data has been stored at the DDSDataReader.

Filtering during the exchange process is performed by a DDSContentFilteredTopic, which is created by the DDSDataReader as a way of specifying a subset of the data samples that it wishes to receive.

Filtering samples that have already been received by the DDSDataReader is performed by creating a DDSQueryCondition, which can then used to check for matching samples, be alerted when matching samples arrive, or retrieve matching samples through use of the FooDataReader::read_w_condition or FooDataReader::take_w_condition functions. (Conditions may also be used with the APIs FooDataReader::read_next_instance_w_condition and FooDataReader::take_next_instance_w_condition.)

Filtering may be performed on any topic, either keyed or un-keyed, except the Built-in Topics. Filtering may be perfomed on any field, subset of fields, or combination of fields, subject only to the limitations of the filter syntax, and some restrictions against filtering some sparse value types of the Dynamic Data API.

RTI Connext contains built in support for filtering using SQL syntax, described in the Queries and Filters Syntax module.

Overview of ContentFilteredTopic

Each DDSContentFilteredTopic is created based on an existing DDSTopic. The DDSTopic specifies the field_names and field_types of the data contained within the topic. The DDSContentFilteredTopic, by means of its filter_expression and expression_parameters, futher specifies the values of the data which the DDSDataReader wishes to receive.

Custom filters may also be constructed and utilized as described in the Creating Custom Content Filters module.

Once the DDSContentFilteredTopic has been created, a DDSDataReader can be created using the filtered topic. The filter's characteristics are exchanged between the DDSDataReader and any matching DDSDataWriter during the discovery processs.

If the DDSDataWriter allows (by DDS_DataWriterResourceLimitsQosPolicy::max_remote_reader_filters) and the number of filtered DDSDataReader is less than or equal to 32, and the DDSDataReader 's DDS_TransportMulticastQosPolicy is empty, then the DDSDataWriter will performing filtering and send to the DDSDataReader only those samples that meet the filtering criteria.

If disallowed by the DDSDataWriter, or if more than 32 DDSDataReader require filtering, or the DDSDataReader has set the DDS_TransportMulticastQosPolicy, then the DDSDataWriter sends all samples to the DDSDataReader, and the DDSDataReader discards any samples that do not meet the filtering criteria.

Although the filter_expression cannot be changed once the DDSContentFilteredTopic has been created, the expression_parameters can be modified using DDSContentFilteredTopic::set_expression_parameters. Any changes made to the filtering criteria by means of DDSContentFilteredTopic::set_expression_parameters, will be conveyed to any connected DDSDataWriter. New samples will be subject to the modified filtering criteria, but samples that have already been accepted or rejected are unaffected. However, if the DDSDataReader connects to a DDSDataWriter that re-sends its data, the re-sent samples will be subjected to the new filtering criteria.

Overview of QueryCondition

DDSQueryCondition combine aspects of the content filtering capabilities of DDSContentFilteredTopic with state filtering capabilities of DDSReadCondition to create a reconfigurable means of filtering or searching data in the DDSDataReader queue.

DDSQueryCondition may be created on a disabled DDSDataReader, or after the DDSDataReader has been enabled. If the DDSDataReader is enabled, and has already recevied and stored samples in its queue, then all data samples in the are filtered against the DDSQueryCondition filter criteria at the time that the DDSQueryCondition is created. (Note that an exclusive lock is held on the DDSDataReader sample queue for the duration of the DDSQueryCondition creation).

Once created, incoming samples are filtered against all DDSQueryCondition filter criteria at the time of their arrival and storage into the DDSDataReader queue.

The number of DDSQueryCondition filters that an individual DDSDataReader may create is set by DDS_DataReaderResourceLimitsQosPolicy::max_query_condition_filters, to an upper maximum of 32.

Filtering with ContentFilteredTopic

Filtering with Query Conditions

Filtering Performance

Although RTI Connext supports filtering on any field or combination of fields using the SQL syntax of the built-in filter, filters for keyed topics that filter solely on the contents of key fields have the potential for much higher performance. This is because for key field only filters, the DDSDataReader caches the results of the filter (pass or not pass) for each instance. When another sample of the same instance is seen at the DDSDataReader, the filter results are retrieved from cache, dispensing with the need to call the filter function.

This optimization applies to all filtering using the built-in SQL filter, performed by the DDSDataReader, for either DDSContentFilteredTopic or DDSQueryCondition. This does not apply to filtering perfomed for DDSContentFilteredTopic by the DDSDataWriter.


RTI Connext Traditional C++ API Version 5.2.0 Copyright © Sun Jun 21 2015 Real-Time Innovations, Inc