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
Now that Npgsql (ADO) is going to be pluggable, the EF Core provider's type mapper also needs to be pluggable - allow external code to inject/override type mappings (e.g. enable Nodatime). This will only work with Npgsql (ADO) vNext, but it makes sense to build it into 2.1.
The same thing has to happen for operations.
Implementation-wise, it may be sufficient for the EF Core plugin to simply get the current service and wrap it with another one which handles the new types. Or I could expose an API to in NpgsqlTypeMappingSource (and the relevant translator services) which allows adding/overriding mappings and translations. The latter seems a bit cleaner and we end up with one place for all the mappings, rather than multiple layers wrapping each other.
@ajcvickers any thoughts on this? I'm guessing this is somewhat relevant to how users will be adding translations for their custom conversions, so it would be good for these to be aligned.
The text was updated successfully, but these errors were encountered:
Yeah, it's very related, let's continue the conversation on dotnet/efcore#11236 (I answered there).
roji
changed the title
Extensible type mapping and method/operator translation
Extensible plugin system for type mapping and method/operator translation
May 15, 2018
Now that Npgsql (ADO) is going to be pluggable, the EF Core provider's type mapper also needs to be pluggable - allow external code to inject/override type mappings (e.g. enable Nodatime). This will only work with Npgsql (ADO) vNext, but it makes sense to build it into 2.1.
The same thing has to happen for operations.
Implementation-wise, it may be sufficient for the EF Core plugin to simply get the current service and wrap it with another one which handles the new types. Or I could expose an API to in NpgsqlTypeMappingSource (and the relevant translator services) which allows adding/overriding mappings and translations. The latter seems a bit cleaner and we end up with one place for all the mappings, rather than multiple layers wrapping each other.
@ajcvickers any thoughts on this? I'm guessing this is somewhat relevant to how users will be adding translations for their custom conversions, so it would be good for these to be aligned.
The text was updated successfully, but these errors were encountered: