You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DuckDBType.Date representation as DateTime/DateOnly #232
System.DateOnly is not available in netstandard2.1, and this causes weird situation when DuckDB.NET is referenced from, say, net8 app (so dates are returned in DbDataReader as System.DateOnly) but when datareader is processed in the netstandard2.1 library it simply cannot handle these values because it knows nothing about this type which even cannot be converted to DateTime (via Convert.ToDateTime, for instance).
It would be helpful to have an option to specify which .NET type use for date-only values (for net6+ builds).
I cannot - this processing is inside the lib, and it simply reads all values via DbDataReader.GetValues(object[]) so it gets values as they are returned by ADO.NET provider implementation. It seems implementations like System.Data.SqlClient, NpgSql, MysqlConnector return DateTime in this case (when no desired type specified) which guarantees 100% backward compatibility.
Those libraries return DateTime because when they were started DateOnly didn't exist. DbDataReader.GetValues(object[]) will box all the values read from the database and unbox when casting to specific type, so I would recommend updating that library and prepare for moving to .NET Core
This makes exactly this particular ADO.NET provider DuckDB.NET incompatible with huge number of libraries that only target netstandard2.0 or netstandard2.1 and if this concrete lib doesn't require any net6/net8/net9 etc specific API, it should not have special builds for these targets.
It is considered that modern NET apps (NET8+) can consume netstandard-compatible libs without problems. That's why it is good idea to return only known types (DateTime instead of DateOnly) for DbDataReader.GetValue and DbDataReader.GetValues methods - and this is how DuckDB.NET netstandard2.1 actually works (it is weird that important API behaviour changes depending on the build, in fact).
In my case, it seems I'll need to wrap DuckDBDataReader with my implementation that will explicitly convert DateOnly to DateTime values.
I understand where you are coming from and it would be good to be compatible with those libraries but it would be great if those libraries moved to .NET Core and added support for modern data type as well as migrate to GetFieldValue. This way those libraries will benefit from increased performance too. Also, it would benefit not only DuckDB.NET users but also other ADO.NET provider consumers. Instead of asking me to be compatible with libraries that don't move forward, I think it's better to ask those library authors (maybe you already have done) to support modern .NET (alongside netstandard if they want to) I'm sure those libraries will benefit from other features that modern .NET has. Until then as you have said you can decorate DuckDBDataReader with your custom reader.
As for specific APIs from modern .NET, this library avoids boxing when reading numeric types on .NET 8:
Activity
Giorgi commentedon Nov 21, 2024
You can use DuckDBDataReader.GetFieldValue<> to read those columns with a desired type.
VitaliyMF commentedon Nov 21, 2024
I cannot - this processing is inside the lib, and it simply reads all values via
DbDataReader.GetValues(object[])so it gets values as they are returned by ADO.NET provider implementation. It seems implementations like System.Data.SqlClient, NpgSql, MysqlConnector return DateTime in this case (when no desired type specified) which guarantees 100% backward compatibility.Giorgi commentedon Nov 21, 2024
Those libraries return
DateTimebecause when they were startedDateOnlydidn't exist.DbDataReader.GetValues(object[])will box all the values read from the database and unbox when casting to specific type, so I would recommend updating that library and prepare for moving to .NET CoreVitaliyMF commentedon Nov 21, 2024
This makes exactly this particular ADO.NET provider DuckDB.NET incompatible with huge number of libraries that only target netstandard2.0 or netstandard2.1 and if this concrete lib doesn't require any net6/net8/net9 etc specific API, it should not have special builds for these targets.
It is considered that modern NET apps (NET8+) can consume netstandard-compatible libs without problems. That's why it is good idea to return only known types (DateTime instead of DateOnly) for DbDataReader.GetValue and DbDataReader.GetValues methods - and this is how DuckDB.NET netstandard2.1 actually works (it is weird that important API behaviour changes depending on the build, in fact).
In my case, it seems I'll need to wrap
DuckDBDataReaderwith my implementation that will explicitly convert DateOnly to DateTime values.Giorgi commentedon Nov 21, 2024
I understand where you are coming from and it would be good to be compatible with those libraries but it would be great if those libraries moved to .NET Core and added support for modern data type as well as migrate to
GetFieldValue. This way those libraries will benefit from increased performance too. Also, it would benefit not only DuckDB.NET users but also other ADO.NET provider consumers. Instead of asking me to be compatible with libraries that don't move forward, I think it's better to ask those library authors (maybe you already have done) to support modern .NET (alongside netstandard if they want to) I'm sure those libraries will benefit from other features that modern .NET has. Until then as you have said you can decorateDuckDBDataReaderwith your custom reader.As for specific APIs from modern .NET, this library avoids boxing when reading numeric types on .NET 8:
DuckDB.NET/DuckDB.NET.Data/Internal/Reader/NumericVectorDataReader.cs
Line 244 in a241693
Also,
LibraryImportrequires .NET 7 and newer and requires lots of#ifdefto support .Net Core and netstandard at the same time.