Rob Spoor wrote:This issue doesn't appear if you use encoding/json to parse to a struct that has an int64 property. For instance:
The map contains a floating point number which has the issue you see. The struct does not.
Geane Norm wrote:Hi,
I have been struggling with an issue with the usage of int64 inside a struct. When parsing into Json in Go and from the 17th digits onwards I have noticed that it starts round the int64 up. For example: 2882795323592627689 => 2882795323592627700
My understanding is that json "numbers" get treated as floating points and therefore they are limited to 53 digits of integer precision. I cannot change my original struct and from the client point of view I still need to have a int64 and it is imperative to have it the same as it identifies a specific request. Can you help with this? This is my current implementation:
Function to convert bytes to int64:
This, in turns, is used inside a function that construct the struct mapping and does the Json unmarshalling:
I have consulted various resources, but with no joy as my main issue seems to be to be able to treat "in a special way" only the int64 in the struct:
Any idea, can you help?
Himai Minh wrote:You may need to use a Json parser such as JSONParser to parse your original Json object and collect the data.
Then, use your data to create a new Json object.
Tim Moores wrote:There are freely available currency conversion WS out there. Either make your WS a proxy for one of them, or retrieve the rates you need to support in regular intervals (might once a day be sufficient? If not, maybe once per hour) and perform the conversion in your WS. I would advise the latter, as the former adds a network round-trip on top of the round-trip to your WS - not a good solution. (It would also raise the question: why use your WS if the client could simply use the other one instead?)
Tim Moores wrote:Just to make sure: the WS returns the exchange rate, and you want that WS to update its data in the background, independently from any client invocation?
What do you mean by "check the rate" - retrieving it from some other remote service?
Given that this is a single data point, I think using Redis would be overkill.
And I don't really see a pub/sub design, given that you're building a WS.