GlobalTypeMapper seems prematurely marked as obsolete

If you’re using an older version of Npgsql which doesn’t yet support NpgsqlDataSource, you can configure mappings globally for all connections in your application:

NpgsqlConnection.GlobalTypeMapper.UseJsonNet(); For this to work, you must place this code at the beginning of your application, before any other Npgsql API is called. Note that in Npgsql 7.0, global type mappings are obsolete (but still supported) - NpgsqlDataSource is the recommended way to manage type mappings.

This is causing grief as adding the recommended NpgsqlDataSource configuration instead, new NpgsqlDataSourceBuilder(...).UseJsonNet();, does not have the same effect (global application), and I currently have rules around warnings that are being triggered by this property being marked as obsolete.

I am arguing that this is premature obsoletion because the data source configuration has no impact on Entity Framework at all. When I read in a column that I’ve typed as Dictionary<string,object> using Json.NET, the object is properly mapped to a string, date, etc. as I need it to be. Without this, it uses System.Text.Json which makes everything a JValue (string). I feel like this could’ve been posted in the EFCore.pg or maybe even the EFCore repo since either of those libraries would ideally allow us to specify JSON configuration options instead of defaulting to one that is also, IMO, premature, and does not allow global serialization/deserialization configuration… So I’m really just looking for some direction on how I can expect to handle this moving forward.

Issue Analytics

State:
Created 4 months ago
Comments:11 (4 by maintainers)

Top GitHub Comments

1reaction

sjd2021commented, May 24, 2023

On an unrelated note, I love the DbDataSource class and am very glad that @roji added it with an excellent explanation on YouTube.

0reactions

sjd2021commented, Jun 5, 2023

@roji We’ve talked before on this and agreed that it does work for the most part with EF for serialization and deserialization which is all I needed it for. I believe that, at least when working with projections, the issue EF has is specifically generating queries to select specific fields within the JSON(B) column.

I’ll spin up a new issue and try to work on a runnable example with a db script, but it will be one entity with a JSON(B) column that is mapped to a Dictionary<string, object>. Newtonsoft handles this beautifully with CLR types while OOTB it will make everything a ValueKind<object> or something else specific to System.Text.Json which is just not all that portable.