Framework types, provider types. extended types and expected types in Npgsql

[Shay Rojansky]

Hi guys. I'm working on the read refactoring and have trouble understanding something - you can probably help with that.

The ADO.NET API supports the idea of a "normal" type and a provider-specific type (GetValue() vs. GetProviderSpecificValue()). Reading the docs, this seems to allow the user to retrieve the column as a special type specific only to the ADO.NET provider. It seems like exactly what's needed to expose, say, a Postgresql-specific date rather than DateTime.

However, in Npgsql we also have the UseExtendedTypes connection string parameter, which affects what GetValue() returns - if's true you get the provider specific value (from GetValue!. Is there any reason for this, or can we just return the .NET framework value from GetValue(), and Npgsql-specific types from GetProviderSpecificValue()?

There's one last type juggling feature in there - expected types. A command has an ExpectedTypes property which is checked first, and returned data is "coerced" into these types. This feature seems to be used only by the EntityFramework. I know almost nothing about how EntityFramework is implemented, but does this belong inside the Npgsql core? Should EntityFramework have a switch based on its "expected type" and just call the correct GetX() method on the reader (e.g. GetDouble())?

Can you guys help shed some light on this?

Shay

[Francisco Figueiredo Jr.]

Em sábado, 22 de novembro de 2014, Shay Rojansky <ro...@roji.org> escreveu:

Hi guys. I'm working on the read refactoring and have trouble understanding something - you can probably help with that.

The ADO.NET API supports the idea of a "normal" type and a provider-specific type (GetValue() vs. GetProviderSpecificValue()). Reading the docs, this seems to allow the user to retrieve the column as a special type specific only to the ADO.NET provider. It seems like exactly what's needed to expose, say, a Postgresql-specific date rather than DateTime.

However, in Npgsql we also have the UseExtendedTypes connection string parameter, which affects what GetValue() returns - if's true you get the provider specific value (from GetValue!. Is there any reason for this, or can we just return the .NET framework value from GetValue(), and Npgsql-specific types from GetProviderSpecificValue()?

When i saw getproviderspecificvalue a long time ago, this was exactly the same idea I had in mind for Npgsql. The problem at the time was backwards compatibility and then we ended up not implementing that. But I did the work of converting the object types which is used in npgsqlcommand. 

Now that we can make breakages regarding backwards compatibility I think making proper use of getvalue and getproviderspecificvalue as you said is the way to go 

There's one last type juggling feature in there - expected types. A command has an ExpectedTypes property which is checked first, and returned data is "coerced" into these types. This feature seems to be used only by the EntityFramework. I know almost nothing about how EntityFramework is implemented, but does this belong inside the Npgsql core? Should EntityFramework have a switch based on its "expected type" and just call the correct GetX() method on the reader (e.g. GetDouble())?

Josh Cooley implemented this. I also don't know anything about entity framework and when I saw his code I thought it was very specific for entity framework and I wouldn't be able to use it for npgsqlcommand. I think that if we could make it work as you are saying, it would be much better. 

But maybe there are things we aren't seeing here and Josh could help us. 

Josh, can you shed some light on this, please? 

Can you guys help shed some light on this?

Shay

--
You received this message because you are subscribed to the Google Groups "Npgsql Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to npgsql-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Regards,

Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://gplus.to/franciscojunior
http://fxjr.blogspot.com
http://twitter.com/franciscojunior