You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The lossless Json parser from #78 needs to be used for the convenience method getJSONVariablesforProcess.
User variables may contain int64 values.
We should allow the user to optionally pass in a class that extends LosslessDto to be able to get the variable data back with no loss of precision.
As a fall-back (when no user Dto is passed in), we could parse it using lossless-json, and then convert any unsafe numbers into BigInt or string.
Making it a string would make it consistent with how we handle int64 in the SDK - however, without metadata about the payload typing, we are reduced to examining the actual payload and we can only detect int64 when the value exceeds the range of the JS number type.
This means that the type of the field would vary depending on the value - which is strange behaviour. This could lead to application errors where string concatenation could occur when arithmetic addition was expected.
The text was updated successfully, but these errors were encountered:
The lossless Json parser from #78 needs to be used for the convenience method
getJSONVariablesforProcess
.User variables may contain
int64
values.We should allow the user to optionally pass in a class that extends
LosslessDto
to be able to get the variable data back with no loss of precision.As a fall-back (when no user Dto is passed in), we could parse it using lossless-json, and then convert any unsafe numbers into BigInt or string.
Making it a
string
would make it consistent with how we handle int64 in the SDK - however, without metadata about the payload typing, we are reduced to examining the actual payload and we can only detect int64 when the value exceeds the range of the JSnumber
type.This means that the type of the field would vary depending on the value - which is strange behaviour. This could lead to application errors where string concatenation could occur when arithmetic addition was expected.
The text was updated successfully, but these errors were encountered: