ADLINK-IST/opensplice

How to find which topic attribute has been updated.

Closed this issue · 1 comments

Hi,

I am trying to find (without sucess) some way to recognize which attribute was updated in an instance, I am doing research between interoperability standards and in the case of DDS I missed this feature. To receive updates of a Keyed Topic, I am using a listener. The problem occurs when I need to know which attributes of the topic have been updated. I'm not sure if the DDS architecture works that way and makes it possible. I would be very grateful if someone could help.

The follow code ilustrate what i have:

virtual void on_data_available(dds::sub::DataReader<T>& dr) // called when the keyed topic is created, updated and deleted
{
        dds::sub::status::DataState new_data; // Mask to get created instances 
        new_data << dds::sub::status::SampleState::not_read()
                 << dds::sub::status::ViewState::new_view()
                 << dds::sub::status::InstanceState::alive();
      
        dds::sub::status::DataState old_data; // Mask to get data that suferred updates, but already exist
        old_data << dds::sub::status::ViewState::not_new_view()
                 << dds::sub::status::InstanceState::alive();

        dds::sub::status::DataState deleted_data; // Instance deleted
        deleted_data << dds::sub::status::InstanceState::not_alive_no_writers();

       dds::sub::LoanedSamples<T> updated_samples = dr.select().state(old_data).read(); // Send to OnCreateInstance() callback
       dds::sub::LoanedSamples<T> new_samples = dr.select().state(new_data).read(); // Send To OnUpdateInstance() callback
       dds::sub::LoanedSamples<T> deleted_samples = dr.select().state(deleted_data).read(); // Send to OnDeleteInstance() ballcak
}

So i have 3 callbacks, but in the callback OnUpdateInstance() (called from the callback above) i can not figure out what is the attribute of that keyed topic that suffers update. This is very important because i want to use the DDS as a DLL (plugin) for a research application, and if i dont know which attribute suffer update, i will need to send the entire topic.

Thank you.

You need to distinguish between 'instances' (represented by unique key-values) and 'samples' of such an instance (that apart from that key-value also have sample-attributes that are non-key-values, like in regular databases).

Now in the DDS-standard, 'instances' have a lifecycle that can either be 'driven' by the publisher-side (an instance might be 'new' if that unique key-value wasn't there before) or by the subscriber side (an instance might be read or not-read).

Now to your question about individual sample-attributes: all attributes of a sample have the same validity i.e. when writing such a sample, all attributes must be filled and when reading a sample, you'll get all samples. Of course you get around this by smart usage of unions (to model optional fields) or exploiting sequences of name-value-pairs which allow you to 'emulate' sparse sample-updates.

There's a set of related patterns that apply to this 'you can't write a half sample' rule: if there are high- and low- update-frequences for certain attributes, you could exploit the relational-database-pattern of creating different topics for those that share the same keys so that the samples can be (natural-)joined on the reader side.

Of course there's another rule that you shouldn't include 'stuff' in a sample that a publisher doesn't understand (also related to that fact that you only publish 'complete' samples).

Note that OpenSplice also allows to model a sample's payload using Google Protocol Buffers (GPB) which does have the concept of optional fields and checking if/what fields have been updated .. but then you'd introduce a dependency on (yet)another standard ..

Hope this helps