Impact of Dictionary Fields changed from 32bit to 64bit?
Hi
We've moved new development to UPA, but we still need to support some of our older product versions that use RSSL 1.3.0 F37.
One of our users is moving from RDMFieldDictionary version 4.00.10 to 4.20.01.
They have noticed that a lot of field definitions have changed types:
REAL32->REAL64
UINT32->UINT64
They want to know if those RDMFieldDictionary changes could cause any problems if they do not change their own code to use 64-bit types.
They use our code, which encodes 32-bit values as REAL32. They would like to avoid changing all of those to 64-bit values. )
More specifically: what happens if their output [with RSSL 1.3.0 F37] is encoded as REAL32, but the downstream user (with the newer RDMFieldDictionary) decodes it as REAL64?
Will it decode successfully?
Will it work, but with possibly bad data?
Or will it fail spectacularly (eg, crash)?
Best Answer
-
The good news is that what you are trying to do is safe.
Encoding as the smaller type (Real32/UInt32/Int32) and decoding as the larger type (Real64/UInt64/Int64) will always succeed because the larger type is encoded/decoded in the same way and can represent all of the values of the smaller type.
The only area where the changes in the dictionary may be noticed is if you have an app encoding the content as a Real64/Int64/UInt64 and an older app trying to decode this as a Real32/Int32/UInt32. In this case, the decoding app will see a failure code for any content that exceeds what it can represent. This is not the case you are encountering, but I wanted to mention it in case it may impact any older test tools that may connect to newer versions of your code that you have changed.
When moving to UPA (as you have likely seen), there are no longer two types for these relationships. UPA only exposes an RsslReal construct and it is always 64 bit. Only older, internal versions exposed RsslReal32 and RsslReal64. At some point when the older code is migrated to UPA it may have to make changes to accommodate for this.0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛