Obtain samples which do not match a querycondition

2 posts / 0 new
Last post
jcwenger's picture
Last seen: 9 months 3 weeks ago
Joined: 01/21/2015
Posts: 11
Obtain samples which do not match a querycondition

I have a FooDataReader with a QueryCondition.  Foo is keyed.  

During my read loop, I need to process all NOT_READ samples, and perform a database update if the last received sample of Foo matches the QueryCondition, and a database deletion if the last read sample does NOT match the queryCondition.

The first case is easy.  I call read_w_condition(), and the condition specifies DDS_NOT_READ_SAMPLE_STATE.

The latter case is messy...

  • I could read_w_condition all the matching samples, and then read all the remaining NOT_READ samples, which should all be mismatches.
    ...But new samples can arrive between the two read() calls.  So I end up getting false negatives that I have to manually test and handle.

  • I could do the two reads above, atomically...  Perhaps by using FooDataReader.lock()/unlock(), which... might... keep new samples from coming in between my read calls???
    ...But lock() is undocmented, so it might not even do what I expect, and it's also not part of the OMG DDS API.  There doesn't seem to be any OMG DDS API method to do an atomic set of read() calls.

  • I could read NOT_READ samples, using no QueryCondition at all, and filter them myself
    ...But there's no API support to do that, so I can't actually use the SQL filter I defined, meaning I have to implement it myself in software.

  • I could make a second QueryCondition, with a query string that is inverse of my criteria.
    ...But this results in extra processing since the filter is evaluated redundantly, twice

Is there another alternative model I could use that will do what I need?

Gerardo Pardo's picture
Last seen: 1 month 2 weeks ago
Joined: 06/02/2010
Posts: 598


I realize you posted this a while ago. So you may have already moved past it...

Of the four options you listed I think the second (using the lock()/unlock() on the DataReader) would be the best approach. Samples may be received on teh network but they will not be placed into the DataReader while you are inside the lock. Yes this is not documented or part of the standard API. But all the other options have the limitations you mentioned so I would say this is the lesser evil.

I cannot think of an alternative. It really would have to be supported natively by the DDS implementation... I agree it is a reasonable use-case so I will enter an request for enhancement in our issue-tracking system based on this use-case but I cannot make commitments as to when/if this would be supported.