Issue 17065: Class for Query Expression (dds-psm-java-ftf) Source: PrismTech (Dr. Angelo Corsaro, PhD., angelo.corsaro(at)prismtech.com) Nature: Uncategorized Issue Severity: Minor Summary: ContentFiltered topics, QueryCondition, and MultiTopic all require a "Query" parameter made by an expression and a set of parameters. The current API, however treats the expression and the parameter as individual parameters and does not provide any abstraction of what could represent a generic DDS query. This makes the API more verbose and more error prone. Resolution --------------- Add a Query class that abstracts over the concept of a DDS query: an expression and a collection of mutable parameters Resolution: Revised Text: Actions taken: January 26, 2012: received issue Discussion: End of Annotations:===== m: Angelo Corsaro Subject: Fwd: [ISSUE: DDS-PSM-Java]: Query expression and parameters should be encapsulated on a Query class To: Juergen Boldt Begin forwarded message: From: Angelo Corsaro Subject: [ISSUE: DDS-PSM-Java]: Query expression and parameters should be encapsulated on a Query class Date: 26 January, 2012 00:49:06 GMT+01:00 To: issues@omg.org, dds-psm-java-ftf@omg.org Cc: Juergen Boldt Name: Angelo Corsaro Employer: PrismTech eMail: angelo@icorsaro.net Specification: Java5 DDS PSM Version: Beta 2 Title: Class for Query Expression Nature: Robustness Severity: Minor Description --------------- ContentFiltered topics, QueryCondition, and MultiTopic all require a "Query" parameter made by an expression and a set of parameters. The current API, however treats the expression and the parameter as individual parameters and does not provide any abstraction of what could represent a generic DDS query. This makes the API more verbose and more error prone. Resolution --------------- Add a Query class that abstracts over the concept of a DDS query: an expression and a collection of mutable parameters. -- 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 ------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------ http://icorsaro.net | http://twitter.com/acorsaro | http://slideshare.net/angelo.corsaro ------------------------------------------------------------------------------------------------------------------ X-Virus-Scanned: amavisd-new at rti.com From: Sumant Tambe To: "dds-psm-java-ftf@omg.org" Date: Tue, 9 Oct 2012 11:59:42 -0700 Subject: Issue #17065: Class for Query Expression Thread-Topic: Issue #17065: Class for Query Expression Thread-Index: Ac2mTZanRKgH5kgiQfe8eG41wsPMLA== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Hi Angelo, Repeating the issue text just for context: Summary: ContentFiltered topics, QueryCondition, and MultiTopic all require a "Query" parameter made by an expression and a set of parameters. The current API, however treats the expression and the parameter as individual parameters and does not provide any abstraction of what could represent a generic DDS query. This makes the API more verbose and more error prone. Resolution --------------- Add a Query class that abstracts over the concept of a DDS query: an expression and a collection of mutable parameters I do see the motivation behind the issue but things will get unnecessarily complicated. DataReader already has an inner interface Query to encapsulate the various ways that an application can search for data to read or take from a DataReader. Objects of this interface are created by the datareader, obviously. Now you are proposing adding another Query interface which will likely be in org.omg.dds.sub package. Datareader methods will accept objects of this suggested type to create QueryCondition. DomainParticipant will use it for creating query-based topics. The issue is .Query. type get quite overloaded in the context of datareaders. That.s why I don.t want to accept the resolution as it is now. With the new proposed Query object we will save only one parameter and it is not clear what to do if the query expression changes. If it has, should a should be thrown? Or should the data reader look at only the new parameters? I don.t see a compelling reason to introduce an .intermediary. between a query expression and query-condition for instance. Existing api is very clean and it allows change in query parameters only. No doubts about whether a query expression has changed. Thanks, Sumant Sumant Tambe, Ph.D. Senior Software Research Engineer 408.990.7429 sumant@rti.com www.rti.com