ulong converted to long raises OverflowException

[andygjp]

Assemblies affected Microsoft.AspNetCore.OData v.8.0.10 Microsoft.OData.Core v7.11.0

Describe the bug Instead of representing row version with a byte array, I want to use a ulong (https://docs.microsoft.com/en-us/ef/core/modeling/value-conversions?tabs=data-annotations#use-ulong-for-timestamprowversion).

By default, ulong is converted to long and any value greater than long.MaxValue causes an OverflowException.

Reproduce steps I've created a repo that contains an example (commented out) and a workaround: https://github.com/andygjp/ODataCustomUnsignedIntVersion/tree/main

Expected behavior Instead of converting ulong to long, it should use another type, either custom or existing (decimal perhaps), avoiding OverflowExceptions and allowing me to do away with my custom conversion.

[corranrogue9]

Hi @andygjp, after discussing it within the team, the issue here is actually with the "on-the-wire" representation. Take the case where a client calls GET /customers and the first entity has an Version of 9223372036854775808 (max long + 1). With the convention that you've provided, the OverflowException might be avoided, but the caller is now receiving a value that cannot be expressed by OData. The standard does not allow for this value. decimal also does not solve the issue for the same reason: if the client provides a value like 1234.5678, that is meaningless to the backing storage, which expects a whole number value.

The only way to address this for both the client and the service looks like if the standard is changed, otherwise this appears to simply be unsupported.

[andygjp]

Hi @corranrogue9,

The convention I've provided is merely a workaround to avoid the issue. Using decimal was the best solution I could come up with. I didn't have many options because of the restrictions of the library and lack of examples. (I did attempt to avoid clients providing decimal numbers by explicitly setting the Scale attribute to 0.)

Its not clear whether support for ulong will be added or not. Will the standard be changed?

Please can you suggest an alternative or point to some documentation/examples which might provide a better solution?

Cheers, Andrew