Yes I agree with Ben’s comments.
Here are some caveats:
This is a feature that is requested by our market data infrastructure team to prevent app dev teams from accidentally publishing incorrect field types.
We don’t believe that a voluntary program will work, which is why the FieldCache as a location is not preferred. Apps won’t use the FieldCache if they don’t need it, or are using an Excel plugin for publishing (quite common).
This is a configured feature, and only for publication.
This is not for subscription, that is, a subscriber can use any of the getXX() methods that work.
There seems to be general agreement that the OM layer is much better place for this feature than bridges themselves.
The two best locations seem to be:
In mamaMsg, in the addXX and updateXX methods, probably with a macro like
that calls out to another module to do the work.
This is good since it keep the message construction in mamaMsg module.
This is good since it give the programmer the quickest feedback on an error condition.
This is bad since it puts some performance hit on construction of every message, even on subscribe.
This is bad since it makes the code active for creating subscribe messages too.
This is bad since it puts more code in more places for this feature.
In publisher.send() that checks a config var and then calls out to another module to do the work.
This is good since it has minimal code changes, and minimal performance effect.
This is good since it only affects publish messages.
This is bad since it gives delayed failure, and there may be multiple fields that fail.
i. Probably logging each failed field and returning an error code will work well to help developers
I think the publisher.send() method is the best place, given the above.
But figuring out which dictionary to use for the checking seems to be the most difficult part.
Adding this feature as a config option may require also adding some optional config info about how to get a dictionary for a specific bridge, e.g., the source
Once the dictionary loading/mapping is solved then the rest seems fairly straightforward, except for the determination of allowed/denied conversions as configurable
policy, but starting with 3 simple ones seems best:
No checking (default)
Type must match dictionary.
Type must match dictionary, with a small number of allowed conversions that do not incur data loss (e.g., F32 -> F64).