Fix ADO.NET description

[Giorgi]

In the readme, you say that:

ADO.NET is flat-table oriented (sublists/subfields are not supported, despite these being probably among the best features of DuckDB).

But it's not true. The DbDataReader has a method GetFieldValue<T> that can be used to read any type of data if the provider implements it. For example, the Postgres provider supports reading lists, enums, and composite types (same as a struct in DuckDB): PostgreSQL enums and composites

DuckDB.NET supports reading lists and enums too. Struct support is not yet implemented but is planned.

[alnkesq]

Yes ADO.NET allows for arbitrary opaque types to be passed through, but they're not first class citizens in the same way as the other "primitive" types. For example if you want to obtain type information about your results, you use DbDataReader.GetName(int), but if you want to go deeper, you'd have to use FieldInfo/PropertyInfo (which is completely unrelated to ADO.NET).

At a certain point I was indeed considering adding an ADO.NET wrapper, but then I asked myself: is it worth the effort when then most ORMs, libraries, LINQ adapters, have weak or no support for such columns? That's also why opted for POCOs + stringy SQL + type generation, instead of a plain standard ADO.NET provider.

I'm not saying it couldn't be added in the future, it's just not what I personally wanted to prioritize.

[Giorgi]

I'm not asking you to implement an Ado.Net provider, but I think the readme should be fixed 🙂

[alnkesq]

I reworded that sentence.

[Giorgi]

I still think that it still doesn't say everything. You can access the data with ADO.Net and can also use Dapper to map Lists as well as Enums. I just added an example: https://github.com/Giorgi/DuckDB.NET/commit/037e20b50a46b8d546f0cb55a901c924b451846c#diff-8f70a4800dcd668efa6fa7b3c5a54e06fb297087981ed765fb314f24299180d0R158