Decimal serialization to POCO results in 0 when containing a comma

ServiceStack.Text
1

I have found that when upgrading from 4.0.56 to 4.5.6 the decimals in my object are all 0. Through investigation I discovered this is due to there being a comma in each decimal of the jsv. Example: "{Test:“1,234.99”}"It appears it may be due to commit: c6ec2061743a248d1a20cd7163243a39634f9926.

Could you explain what this change was for and if there is another way to fix the serialization? Why was it not done for nullable decimals?

2

I’ve added a test for this that’s working as expected in this commit.

Can you provide a test that fails please.

3

Certainly. In the second assertion “Decimal” will be 0. If you change the properties to nullable types the test passes.

    [Test]
    public void Can_serialize_ModelWithFloatTypes_From_String()
    {
        var dto = new ModelWithFloatTypes
        {
            Float = 1111.1f,
            Double = 2222.2d,
            Decimal = 3333.3m
        };

        var jsv = "{Float:\"1111.1\",Double:\"2222.2\",Decimal:\"3333.3\"}";
        var fromJsv = jsv.FromJsv<ModelWithFloatTypes>();
        Assert.That(fromJsv, Is.EqualTo(dto));

        jsv = "{Float:\"1,111.1\",Double:\"2,222.2\",Decimal:\"3,333.3\"}";
        fromJsv = jsv.FromJsv<ModelWithFloatTypes>();
        Assert.That(fromJsv, Is.EqualTo(dto));
    }
4

It’s not expecting the numbers to be formatted and doesn’t serialize them as such. So they should be left in their expected state. Where did the formatted numbers come from?

5

The data is coming from one of our internal, non-ServiceStack, system. We can remove the formatting to fix the service we identified the issue with. The problem is that we do not know what other services this issue may occur with. We do not receive an exception as the Decimal populates as 0. The result is unexpected as it does behave the same across all data types nor nullable types.

Right now we are forced to hold off on the upgrade until we have a means to detect all affected services and correct the formatting from the request, or determine a way around this limitation by stripping the formatting from string to decimal conversions.

The ideal change would be if I could specify the NumberStyle is a currency or have it detected.

6

ServiceStack Serializers are designed to be resilient by default and deserialize as much as it can without error. If you want it to throw an Exception when gets a deserialization error you can configure it with:

JsConfig.ThrowOnDeserializationError = true;

The Serializers are only designed to support what it serializers so it should match the serialized output, but I’ll look into seeing if we can make it fallback to accept these formatted numbers as well.

7

Ok I’ve added support for deserializing formatted decimals with commas and added tests for nullable floats in this commit.

This change is available from v4.5.7+ that’s now available on MyGet.

8

Great update. That solved the problem. Thank you!