Issue 17063: Condition classes should only be used with WaitSets (dds-psm-cxx-rtf) Source: (, ) Nature: Clarification Severity: Significant Summary: The DataReader API provides methods to read samples with a condition. This condition can be either a ReadCondition or a QueryCondition, and in this case the samples returned are either filtered by the status (ReadCondition) or the content+status (QueryCondition). The ReadCondition is completely in overlap with the instance/status/view states and its use is really irrelevant when in combination with the DataReader. On the other end the only aspect of the QueryCondition that really matters to a DataReader are the query expression and parameters. By looking carefully at the API, it seems apparent that the ReadCondition and the QueryCondition really make sense only when used with a WaitSet. On the other end, their use in conjunction of a DataReader is a stretch and breaks the semantics of the "Condition". On principle a condition is used to "wait" for a particular status to be true, yet the DataReader "read" are -- rightfully -- always non-blocking. In addition, the API opens up for gratuitous runtime errors as I could write silly code as follows (in C++): auto rc = reader.create_readcondition(); reader2.read(..., rc,...); This although silly is allowed by the API and on a proper DDS implementation should raise an exception. The same could happen with a QueryCondition! Resolution --------------- Limit the use of Read/QueryCondition to waitsets and put in place a more robust mechanism to do status and content filtering on a data-reader read. An example of what could be done is provided below, where I assume that the DataStatus is the former ReaderState: reader .filter_status(DataStatus::new_data()) .filter_content(Query("x < 100 AND y < 100")) .read(); Equally, one could write (again legal C++ below with little magic under-cover) : reader .instance(handle) .filter_status(DataStatus::new_data()) .filter_content(Query("x < 100 AND y < 100")) .read(); Notice that this code, not only is very declarative and thus shows very clearly the intent of the programmer, but in addition does not allow for the silly mistakes shown above. Further more, it really highlights he role of the Sample/Instance/View status as a "filter" on the status of data. Resolution: Revised Text: Actions taken: January 26, 2012: received issue Discussion: End of Annotations:===== m: Angelo Corsaro Subject: Fwd: [ISSUE: ISO C++ / Java 5 DDS PSM]: Read/Query Condition should only be used with waitsets and not with DataReader To: Juergen Boldt Begin forwarded message: From: Angelo Corsaro Subject: [ISSUE: ISO C++ / Java 5 DDS PSM]: Read/Query Condition should only be used with waitsets and not with DataReader Date: 26 January, 2012 01:58:38 GMT+01:00 To: dds-psm-cxx-ftf@omg.org, dds-psm-java-ftf@omg.org, issues@omg.org Cc: Juergen Boldt Name: Angelo Corsaro Employer: PrismTech eMail: angelo@icorsaro.net Specification: Java5 DDS PSM / ISO C++ DDS PSM Version: Beta 1 Title: Condition classes should only be used with WaitSets Nature: Clarity Severity: Moderate Description --------------- The DataReader API provides methods to read samples with a condition. This condition can be either a ReadCondition or a QueryCondition, and in this case the samples returned are either filtered by the status (ReadCondition) or the content+status (QueryCondition). The ReadCondition is completely in overlap with the instance/status/view states and its use is really irrelevant when in combination with the DataReader. On the other end the only aspect of the QueryCondition that really matters to a DataReader are the query expression and parameters. By looking carefully at the API, it seems apparent that the ReadCondition and the QueryCondition really make sense only when used with a WaitSet. On the other end, their use in conjunction of a DataReader is a stretch and breaks the semantics of the "Condition". On principle a condition is used to "wait" for a particular status to be true, yet the DataReader "read" are -- rightfully -- always non-blocking. In addition, the API opens up for gratuitous runtime errors as I could write silly code as follows (in C++): auto rc = reader.create_readcondition(); reader2.read(..., rc,...); This although silly is allowed by the API and on a proper DDS implementation should raise an exception. The same could happen with a QueryCondition! Resolution --------------- Limit the use of Read/QueryCondition to waitsets and put in place a more robust mechanism to do status and content filtering on a data-reader read. An example of what could be done is provided below, where I assume that the DataStatus is the former ReaderState: reader .filter_status(DataStatus::new_data()) .filter_content(Query("x < 100 AND y < 100")) .read(); Equally, one could write (again legal C++ below with little magic under-cover) : reader .instance(handle) .filter_status(DataStatus::new_data()) .filter_content(Query("x < 100 AND y < 100")) .read(); Notice that this code, not only is very declarative and thus shows very clearly the intent of the programmer, but in addition does not allow for the silly mistakes shown above. Further more, it really highlights he role of the Sample/Instance/View status as a "filter" on the status of data. -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 ------------------------------------------------------------------------------------------------------------------ http://icorsaro.net | http://twitter.com/acorsaro | http://slideshare.net/angelo.corsaro ------------------------------------------------------------------------------------------------------------------ -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 ------------------------------------------------------------------------------------------------------------------ http://icorsaro.net | http://twitter.com/acorsaro | http://slideshare.net/angelo.corsaro ------------------------------------------------------------------------------------------------------------------