Yes that’s why I was suggesting this approach – it’s backwards compatible with existing bridges (we can make the bridge methods optional now where no implementation exists) and it doesn’t

I’d be cautious about that one, Frank – you’d need to think about the implications for the payload bridges because you’d need valid representations for NULL for all field types (or possibly

For the record, I’m not opposed to a “first class” null data type in principle. Json and msgpack for example have it fine. It does raise a bit of ambiguity though on how to handle a NULL value

For integers, yes, I agree. For dateTimes, as I said, you can indicate if the date part is valid or the time part is valid (hasDate()/hasTime()/setHints()). If neither flag is set, we interpret that

Thanks Nigel – I am with you now. Was not aware of the ‘setIsValidPrice()’ method. Our version of the tick42rmds bridge does not use it when translating messages received, but it could be

Still not sure I see the problem, Keith. If you receive the data as a string field and, when the transport bridge tries to map it to a mamaPrice field, the conversion fails, you should call

Hi Nigel, I don’t have a RIC to quote here, but the problem exists for certain data delivered over the Elektron feed, with data from contributors where we have no control over what conventions

Hi Keith – what we normally do here is use the relevant getters/setters on the Price and DateTime fields (getIsValidPrice, setIsValidPrice, HasDate, HasTime). We tell people to render blanks for

Certain other market data platforms / APIs (well, TREP) support the concept of 'blank' field values. The price and time field types actually have special blank data representations defined. This is

Hi Folks, We are pleased to announce OpenMAMA 6.3.0 is finally here! This is a bridge interface updating release which fixes several outstanding bugs and introduces some new functionality. OpenMAMA

Hi Folks, Looks like we will be wrapping this up in the middle of next week – so far no major issues reported. Cut off date is Wednesday next week. Cheers, Frank Frank

Hi Folks, RC2 now available with artefacts: https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc2 Let’s aim for a 2 week test window so please get testing! Cheers, Frank

NB: Further Bridge Interface change in OpenMAMA 6.3.0 Hi Folks, As suggested by Chris over at Solace (and with my agreement), I think this is a good time to correct one of the interface

Sorry just as a quick correction, the list of issues is in this link, not the one in the previous email: https://github.com/OpenMAMA/OpenMAMA/milestone/10?closed=1 (thanks Chris)

Hi Folks, Sorry for the delay I hit a few snags trying to get the release together, but it’s finally ready! https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc1 Note that this

My two cents here, the Docker PR looks solid and I think is good to merge. I suspect the MAMDA QuoteCache fix (392) should be landed before any cut, even if it means a delay, but apart from that I

Hi Folks, It’s that time again where I think we need to consider making a new OpenMAMA release. I’ve just raised a pull request for Docker which was the last main piece of new

Hi Frank, Thanks for your message, and for raising the associated issue in Github. We have discovered that the MamdaQuoteToBookListener.cpp file is not present in the SConscript.win build

Hi Mike, This isn’t something that I have seen before but it does look like a bug to me… and one which I imagine you had all sorts of fun tracking down. On the upside, it looks like the

Hi all, We have noticed that both mamda/c_cpp/src/cpp/MamdaQuoteListener.cpp and mamda/c_cpp/src/orderbooks/MamdaQuoteToBookListener have implementations of a QuoteCache struct in the Wombat