I raised this issue on the github project for RazorJam.Insightly, where as you can see it turns out that an error is occurring because for the particular items that I am retrieving and deserialising from JSON into an object, the ADDRESS_ID value is too large to fit into an int.

I initially wanted to submit a change request amending all the Id fields that I coulld find to type string or long, but wasn't sure which would be best.

Then there is also the possibility of first checking the length and then assigning based on whether or not it will fit into an Int32, but perhaps this is not the best option as it adds more code and probably affects performance.

However, due to the fact that other people may be using this code, changing the type might break their projects if they are relying on an int value coming through, so maybe checking is the best option?

I can of course just save a local copy and make whatever change I want, but it seems best to have a public version which just works for everyone.

Simple Illustration

Current Implementation

[JsonProperty(PropertyName = "ADDRESS_ID", NullValueHandling = NullValueHandling.Ignore)]
public int Id { get; set; }

Option 1

[JsonProperty(PropertyName = "ADDRESS_ID", NullValueHandling = NullValueHandling.Ignore)]
public string Id { get; set; }


[JsonProperty(PropertyName = "ADDRESS_ID", NullValueHandling = NullValueHandling.Ignore)]
public long Id { get; set; }

Option 2

private object _id;

[JsonProperty(PropertyName = "ADDRESS_ID", NullValueHandling = NullValueHandling.Ignore)]
public object Id
    get { return _id; }
    set { _id = (long)value > int.MaxValue ? (long)value : (int)value; } }

Does anyone have any thoughts or advice they can share on this? Any help is much appreciated, and apologies if this is the wrong forum for this!


String is the safest option for translating numbers back and forth from Json and C#. JSON has limitations on precision that may cause issues on large integer numbers. According to the JSON spec, implementations should limit precision to that of a double precision (64-bit) number. For example the long number 767946224062369796 which can be represented exactly by a C# long, cannot be represented as a double precision floating point number, and may be parsed as 767946224062369792 by JSON decoders. For identifiers precision is of the utmost importance, so I would recommend you recommending to them to use a string identifier.

You could use a BigInteger, but since it's an ID and not used in math, there isn't much reason to.

As you've said, this will be a breaking change, so they may decide not to do it, or it may have to wait until the next major version.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.