Fix breaking change to LogicalTypeEnum.None value

[adamreeve]

Fixes #443

[marcin-krystianc]

Writing this enum type converter seems to be an overkill, but on the other hand there is rather no other option. In large solutions, there is a high chance of having projects compiled against ParquetSharp pre-15.0.2 and 15.0.2, which would cause hard to debug errors at runtime.

PS:
What an odd decision to put the None as the lat value in the enum. It guarantees that each time a new value is added, the value of None needs to be changed as well.

[marcin-krystianc]

Should we implement additional measures to prevent such mistakes in the future?

[adamreeve]

PS: What an odd decision to put the None as the lat value in the enum. It guarantees that each time a new value is added, the value of None needs to be changed as well.

Yeah, this is a little unfortunate and if we'd foreseen this problem we could maybe have mapped None to something different to what the C++ library uses that wasn't going to clash with a future value.

Should we implement additional measures to prevent such mistakes in the future?

This is a good idea, we have some checks that detect if the C++ enum values change (

ParquetSharp/cpp/Enums.cpp

Line 40 in 9fba131

static_assert(LogicalType::Type::UNDEFINED == 0);

) but I only thought that meant the C# enums needed updating, I missed that this would break the ABI. Maybe we could have some automated tests that build tests against older versions of ParquetSharp and then run them with the current build, which should detect a range of different ABI breaking scenarios.