Hi,
Let's assume I have a topic A whom data type is like:
struct myStruct {
short A_id; //@key
string A_title;
string A_data; };
Then I create 3 instances and I write them from my Datawriter to my Datareader.
What I'd like to do is to set a ContentFiltered topic on the reader's side in order to filter out every fields except the 'A_title' one from every instance I receive.
So I tried it using a SQL expression (something like "SELECT A_title FROM A") for my filter expression but I keep getting errors at the creation of the content filtered topic since my syntax is obviously wrong.
So my questions are : Is that even the right way to resolve my filtering issue ? (I mean creating a cft with a SQL filter expression)
And if it is, what would be the correct syntax ?
Thanks for your help,
Stephane
Hi Stephane,
Section 5.4.6 in the RTI Core Libraries and Utilities User's Manual explains the syntax of the SQL expression for ContentFilteredTopics (in BNF form).
Looking at your expression, it should be similar to what you specified. Are you missing the ending semicolon?. "SELECT A_title FROM A WHERE <your filtering condition>;"
Thanks,
Juanlu
Hi,
I think there's a disconnect between what a CFT does and what you are trying to do. The CFT SQL built-in filter is only looking for the Where clause in the SQL -- "where A_title = 'Foo'" would pass all samples (and all of their fields) where A_title = 'Foo'. It does /not/ return "just the A_title field" of every instance, which is why a "select A_title from A" is not going to work.
To reduce the sample, you will have to implement your own mediation. You can do this in your reader implementation (or inside a custom bridge, for example a Routing Service adapter), but DDS won't do it for you.
Did I understand your statement correctly?
Regards,
Rip
Hi rip, yes I guess you did understand my issue, so if I did understand your answer, there's no kind of filter that could prevent my application from receiving every fields of my instance, is that right ?
Thanks again,
Stephane
Hi,
Yes. There is no defined DDS behavior like this, it would have to be implemented at application level.
rip
Alright, so would you say an alternative to this would be for me to use Dynamic Data and sparse values on the sender side ?
Thanks,
Stephane
If you are using 5.1.0, you have access to optional types (part of the Extensible Types standard).
Mark the unneeded fields as Optional (in the IDL), and then leave them as null in the data to be written. If you are only trying to update specific fields in a larger Type, you'll need to do the reassembly yourself.
Thanks a lot for your answers !
Stephane