Composite versioning in regards to OTF decoding

[michaelpking]

Hi,
I seem to be having an issue with the c++ OTF decoder in my current project. I'll lay out what I believe is happening and see if someone has a suggested way to work around or if I'm "doing it wrong".

Using a IR file based on a later message schema (say version 2) to decode a message that was encoded with an earlier version of the message schema (version 1) doesn't seem to supply enough information during the token listener callback framework when dealing with composites.

What appears to be happening is that the token for the composite and constituent fields of the composite aren't inheriting the sinceVersion of the message but the type definition itself, kind of a class vs. instance issue.

<messageSchema version=2....
<types>
<composite name="myreusablefield" sinceVersion="1">
<type name="field1" primitiveType="int64">
<type name="field2" primitiveType="char">
</composite>
...
</types>
<message name="mymessage" id=........
<field name="messagefield1" type=uint15 sinceVersion="1"
<field name="messagefield2" type="myreusablefield" sinceVersion="2"
......
</message>
</messageSchema>

The token for "field1" that's part of the type "myresuablefield" of instance "messagefield2" has no sinceVersion/actingVersion. So at the time of callback one cannot skip the processing of the field as it appears to be a valid actingVersion in the code for version 2 of the schema despite the fact the encoder was using schema version 1 thus impossible to encode the field.

Am I understanding this correctly and there's not some other place associated with onEncoding that already supplies this on the callback?

My plan is to implement my own stack based approach to override any token's actingVersion if the top most encapsulating composite is has it's acting version defined. One needs to also account for nested composites as well but not 100% as a non-SBE spec expert. Of course if the sbetool could handle encoding the nested actingVersion with a code update, I'd be golden :)

[michaelpking]

for what it's worth, I implemented a stack based actingVersion tracker for composites (and nested composites) that solved my problem. My otf library now behaves like the generated code, skipping a composite and all encapsulated fields/composites. The sbetool still could use an upgrade to properly walk the schema and apply the proper actingVersion on each and every token

[michaelpking]

you da man @mjpt777 !