-
-
Notifications
You must be signed in to change notification settings - Fork 728
Typeless decimal serialized as string #651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Preserving integer types is tracked by #425 |
Ok, it looks like the I guess that's because there's no better format that retains all the precision that Decimal guarantees. The shortcoming then seems to be that the typeless formatter doesn't recognize this type as needing a type annotation, and as a result simply deserializes it using the type it appears to be in the msgpack sequence. @neuecc Do you already have a pattern for dealing with this? |
Demonstrates bug MessagePack-CSharp#651
I added a test case for this. We'll merge it hopefully with a fix, or I might merge it as a skipped test just to document the bug if we can't fix right away. |
for DateTime, Typeless already using |
So should we get this in for 2.0 then on the backward compat basis? |
Demonstrates bug MessagePack-CSharp#651
Adding I think we should solve this by adding a type annotation extension when we serialize guid's or decimals when they were statically typed just as |
v1-> v2 should have binary compatible. |
So we resolve this as Won't Fix then? I don't see any alternative without some kind of msgpack formatter change. |
You can create a binary compatibility formatter for Typeless that determines the type when deserializing (string or binary). |
I am trying latest stable nuget package as of 2/18/2013. Guid and decimal will be string after serialization and deserialization. I have a property whose type is object/dynamic, since it generic ID for any entity, could be composite key, could be any type. Is there a way to preserver run time type info for each object when serialization and use it for deserialization? |
@RyanLiu99 Please don't double post. |
Bug description
Types are deserialized as different incompatible types (e.g. int as uint, decimal as string).
Examples
Yes the specification of MessagePack allows to pack numeric values into smaller data types.
However, the deserialized type should be the one it had when it is serialized.
Problem 1
Packing the values into smaller types is less of a problem, but there are two things which are:
the MediumSizedInt which is unpacked as uint, which means the unpacked value cannot be safely cast back to the int.
Problem 2
Unpacking the decimal as a string. It is fine to use this as a intermediate packing, but once unpacked it must be a decimal again, as this is not even a numeric value anymore.
Problem 3
Which culture variant rules are used for decimal to string conversion. There is a huge difference on how to convert a string back to a decimal. How can I specify which rules should be used?
Repro steps
Run the XUnit test cases.
Expected behavior
No matter what format is used during packing, the unpacked types should match the original or a smaller type which can be safely assigned to the larger one.
Actual behavior
The types changed from int to uint and from decimal to string.
The string case is in particular dangerous as string serialization is culture variant.
Other resources
See messagepack-c for a similar issue: msgpack/msgpack-c#247
The text was updated successfully, but these errors were encountered: