Saving/restoring with LengthUnit (or any enum) changing

[matthewtrahan]

In our application, we heavily use UnitsNet for most of our data. We use a file based approach for data storage and serialize/deserialize everything, including UnitsNet information like the unit. We've gone back and forth on the "correct" way to do this, whether it be saving a LengthUnit enum string or the backing int value and have run into problems in both cases as UnitsNet changes. In our latest upgrade of the package, we have some data saved before the upgrade with a LengthUnit value of 10 which now pointing to a LengthUnit.Fathom instead of a LengthUnit.Foot which throws things off for us. We've also had a similar case where the enum string has changed which causes the same issue.

Do you have any suggestions for how to deal with the LengthUnit enum order/strings changing? We've previously mapped the old strings to new strings and can do something similar for the order change but I just wanted to check in and see if there's a known better way to do this or any other ideas we haven't considered yet.

Thank you,
Matthew

[angularsen]

Hi, we recently tackled the issue of volatile enum integer values.
#1097

So as of v4.133.0, at least the enum values should now be stable.

However, occasionally we do rename units by deprecating it and creating a new unit, to fix typos or ambiguous naming such as Gallon -> UsGallon. This means you get a new enum name and value for the equivalent unit.

I haven't thought much about this in a long time, but I see a few ways to handle it:

1. Map to your own types for serialization

Create your own enum types and your own DTO types, similar to UnitValue provided by UnitsNet.Serialization.JsonNet.
Then map from/to UnitsNet types when reading or writing from storage.
This works best if you only need to support a small subset of the quantities and units that do not change.

Pros:

• You are 100% in control of any changes to the serialized data, and how to migrate any changes.

Cons:

• Each consumer would have to create their own serialization types and mapping.
• A lot of work to support "all" current and future quantities and units, must be kept up to date.
• Might not easily help with JSON data already serialized with UnitsNet.Serialization.JsonNet

2. Shared forward-mapping of deprecated units for everyone to use

Say, if Gallon=1 was deprecated and replaced with a new UsGallon=2 unit enum value, and then UsGallon is later deprecated in favor of SuperGallon=3, then we could call MapDeprecatedUnit(VolumeUnit.Gallon) and get VolumeUnit.SuperGallon out.

I believe a switch statement and recursively calling itself until a non-deprecated unit is resolved should do the trick.

However, in v5 we remove several deprecated units, so that complicates the mapping if the serialized string "Gallon" no longer exists as a unit enum. I assume UnitsNet.Serialization.JsonNet will fail to deserialize units that have been removed, so the mapping would have to be performed either before deserialization or the converter could be modified to fix it during deserialization.

UnitsNet.Serialization.JsonNet would requires some name-based mapping, while other custom serializations might require integer-based mapping, so I guess we would have to support both. As of 4.133.0 the integer values are now stable at least, also when removing units.

This mapping could be maintained in UnitsNet repo, so if you do decide to take this approach it would be great if you could contribute it to the repo so it can be maintained there.

Pros:

• Shared mapping that all consumers can benefit from, maintained in a single place.
• Can be made to work out of the box with UnitsNet.Serialization.JsonNet
• Can be made to work for custom serialization

Cons:

• Might take some effort to make it work as expected for everyone, there are probably some challenges I have not yet thought of

Let me know what you think, and whether you would be interested in attempting a pull request for option 2.
I'm happy to help, but I don't have the time to implement this myself.