Repository navigation
Conversation
…rmat DecimalCodec.EncodeDecimal wrote coefficients with more digits than the format allows, and exponents outside its range, without any check (only a Debug.Assert). In Release builds the excess bits overflowed into the combination/exponent fields and the server stored a different value, e.g.: 12345678901234567890123456789012345 -> DECFLOAT(34) stored 8345678901234567890123456789012345 30000000000000004E-17 -> DECFLOAT(16) stored 0.08000000000000004 1E400 -> DECFLOAT(16) stored 8.000000000000001E-353 The encoder now brings the value into the format's ranges without changing its numeric value (dropping trailing zeros of the coefficient, folding the exponent into the coefficient, clamping the exponent of zero), and throws OverflowException when the value cannot be represented exactly (too many significant digits, exponent overflow or underflow). Values that previously got corrupted although representable (e.g. 1E384 in DECFLOAT(16)) now work.
The conversions formatted the value with a fixed custom format and then
removed the decimal point, assuming one was present. This threw
ArgumentOutOfRangeException for every value without a fractional part,
e.g. (FbDecFloat)1m, (FbDecFloat)100m, (FbDecFloat)2.0, and for values
smaller than the format's decimal places, e.g. (FbDecFloat)1e-20. It also
dropped the scale of decimals (1.10m became 1.1) and digits beyond 15
decimal places of doubles (7 for floats).
- decimal: converted exactly from its 96-bit integer and scale, so the
value and its scale are preserved (1.10m -> 110E-2), including -0.
- double/float: converted to the shortest decimal that round-trips to the
same binary value ("R" format), e.g. 0.1 -> 1E-1, 0.1 + 0.2 ->
30000000000000004E-17, 1e-20 -> 1E-20; -0.0 -> negative zero.
A converted double may have up to 17 significant digits; sending it to a
DECFLOAT(16) throws OverflowException instead of being silently rounded
(this relies on the encoder range check of the previous commit).
Random.NextInt64() never returns a negative value, so the random doubles were all positive. Use the full long range and assert both signs are covered.
Parameters: a DECFLOAT parameter only accepted FbDecFloat; any other value (decimal, double, int, ...) threw InvalidCastException, even when the parameter was created by AddWithValue with a decimal. Values of type decimal, double, float, the integral types and BigInteger are now converted to FbDecFloat (decimal exactly, double/float to the shortest round-trip value). A value that does not fit the DECFLOAT precision exactly throws OverflowException instead of being rounded. Reader: GetDecimal, GetDouble, GetFloat, GetInt16/32/64 and GetByte (and the matching GetFieldValue<T>) on a DECFLOAT column threw InvalidCastException because FbDecFloat is not IConvertible. Now: - GetDecimal: exact, keeping the scale (1.10 -> 1.10m); OverflowException when the value cannot be represented exactly (too large, too many digits, NaN, infinity). - GetDouble/GetFloat: nearest value, like on NUMERIC columns; NaN and infinities are mapped, out-of-range values become infinity or zero. - Integer getters: nearest integer, ties to even, as Convert does for decimal columns; OverflowException when out of range, NaN or infinity. FbDecFloat gets the matching public explicit conversions to decimal, double and float.
- Provider: add net11.0 to TargetFrameworks. No Microsoft.Extensions.Logging.Abstractions package reference is needed for net11.0: the assembly ships in the .NET 11 shared framework, and NuGet prunes the reference (the nuspec net11.0 group is empty). - Tests: multi-target FirebirdSql.Data.FirebirdClient.Tests to net10.0;net11.0 so TFM-specific code paths are exercised on both. - tests.ps1: copy the Firebird binaries into, and run the FirebirdClient suites from, every provider test TFM output. - CI: install the .NET 11 SDK (preview quality until 11.0 GA).
.NET 11 introduces the IEEE 754 decimal floating-point types Decimal32, Decimal64 and Decimal128. Their decimal interchange encoding (EncodeDecimal/DecodeDecimal, densely packed decimal) is the encoding of Firebird's DECFLOAT(16)/DECFLOAT(34): the provider's DECFLOAT codec and .NET agree bit for bit (asserted by a seeded test over random values and all special values), so the conversions are exact, including the exponent (1.10 stays 1.10), negative zero, infinities and NaNs, with no text round trip. On net11.0 only: - FbDecFloat: explicit conversions from Decimal32/Decimal64/Decimal128 (exact) and to Decimal64/Decimal128 (exact, OverflowException when the value does not fit). - Parameters: Decimal128 values infer FbDbType.Dec34, Decimal64 and Decimal32 infer FbDbType.Dec16. They can be passed to any numeric parameter; a value that does not fit the target exactly (e.g. a 34-digit Decimal128 into DECFLOAT(16)) throws OverflowException instead of being rounded. - Reader: GetFieldValue<Decimal128>() and GetFieldValue<Decimal64>() for DECFLOAT and the other numeric types (exact, OverflowException when the value does not fit). GetValue()/GetFieldType() still return FbDecFloat for DECFLOAT columns.
Every parameter value reaches DbValue through FbParameter.InternalValue (FbCommand and FbBatchCommand, sync and async), so Decimal32/64/128 values are converted to FbDecFloat there. DbValue no longer checks the type of every value it stores: both clients store decoded row values in DbValue (the managed client through the constructors, the native client through SetValue), and those values are never IEEE decimals. DbValue's constructors and SetValue are back to their previous code. Adds a batch command test (Decimal64/Decimal128 parameters, bit-exact round trip), as FbBatchCommand takes the same path.
…/Decimal128 With "DecFloat Type=Ieee754" (FbConnectionStringBuilder.DecFloatType = FbDecFloatType.Ieee754), DECFLOAT(16) values are returned as System.Numerics.Decimal64 and DECFLOAT(34) values as Decimal128 by FbDataReader.GetValue/GetValues/indexers/GetFieldValue<object>, GetFieldType/GetSchemaTable (so DataTable/DataAdapter columns get those types), FbCommand.ExecuteScalar and output parameters. The default, FbDecFloatType.FbDecFloat, keeps the current behavior. Ieee754 requires .NET 11 or later: on older target frameworks the option is rejected when the connection string is validated. The conversion is exact (the field's precision always fits the IEEE type), and the typed accessors (GetFieldValue<FbDecFloat>, GetDecimal, ...) are unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #1302. Based on #1308.
Summary
Adds the opt-in connection string option
DecFloat Type. WithDecFloat Type=Ieee754, DECFLOAT(16) values are returned asSystem.Numerics.Decimal64and DECFLOAT(34) values asDecimal128wherever the provider chooses the CLR type. That way, code that relies onGetValue/GetFieldType, such asDataTable/FbDataAdapter(tested below), gets the .NET types. The default (FbDecFloat) keeps the current behavior.The names are open for discussion (see #1302). The enum member
FbDecFloatType.FbDecFloathas the same simple name as the structFirebirdSql.Data.Types.FbDecFloat, which is legal but maybe not ideal.Changes
FbDecFloatType { FbDecFloat, Ieee754 }, connection string keydecfloat type(synonymdecfloattype), andFbConnectionStringBuilder.DecFloatType.Ieee754requires .NET 11: on older target frameworksConnectionString.Validaterejects it.FbDataReader.GetValue,GetValues, the indexers andGetFieldValue<object>,GetFieldType,GetProviderSpecificFieldTypeandGetSchemaTable,FbCommand.ExecuteScalarand output parameters.GetFieldValue<FbDecFloat>,GetDecimal, ...) are unaffected. The conversion is always exact, because the field precision fits the IEEE type.Tests
ConnectionStringTestsandFbConnectionStringBuilderTests: default, parsing, synonym, invalid value, validation per TFM, builder setter and getter.FbDecimalIeee754SupportTests(net11.0): field types, values, NULL, other columns unchanged, schema table,ExecuteScalar, stored procedure output parameters,FbDataAdapter.Fill. Without the reader/command changes, these 4 tests fail.