{{ message }}
Repository navigation
Consider allowing unmapped enums to be written as int/string #3303
Description
@mikependon did a lot of comparative work on enum coercion across ADO.NET providers (thanks @mikependon!) - the results can be seen here: https://twitter.com/mike_pendon/status/1325442299862659074.
Bottom line:
- When DbType.String or DbType.Integer are set, enums are properly coerced by all providers except Npgsql
- When DbType isn't set, some inconsistent behavior occurs, e.g. the int value would be textually saved in text columns in some cases.
I don't think we should support this without DbType (especially in light of the weird/problematic behavior across providers), but we should consider aligning with others and at least allowing DbType.String/Integer.
Activity
mikependon commentedon Dec 13, 2020
@roji never saw this on the latest release, when do think is the timeline of this? I am asking due to our internal schedule of RepoDB's release, maybe we can include the changes to this as well if necessary.
YohDeadfall commentedon Dec 13, 2020
#3389 changed the behaviour of the driver by allowing writing of unmapped enum without setting up a command parameter.
roji commentedon Dec 13, 2020
@mikependon @YohDeadfall note that #3389 is quite different from this. #3389 is about allowing sending CLR enums to PostgreSQL enums, without mapping them beforehand. This issue is about allowing coercing CLR enums to PG int/text by using DbType.
mikependon commentedon Dec 13, 2020
@roji - thanks, I am about to test it actually. Anyway, I will just wait for the fix for this one then, before doing the changes on our compiler. Do you have the timeline for this?
roji commentedon Dec 13, 2020
I'm not sure this is something we'll patch, so it'll probably only be out in the next version, which is probably months away (we just released 5.0).
NinoFloris commentedon Apr 21, 2026
Most of this can be made to work quite nicely on .NET 10 once #6317 is merged. Though full support for all our array mappings (List<T> and any future types applied to all array mappings) must always require an explicit registration.
TEnum[] (and multidim cases) will work without explicit registration due to how NAOT handles array types in special ways. Read requests for interfaces implemented by TEnum[] today don't quite work though. I've opened a runtime issue about this here: dotnet/runtime#127249.