Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider allowing unmapped enums to be written as int/string #3303

Open
roji opened this issue Nov 8, 2020 · 5 comments · May be fixed by #4838
Open

Consider allowing unmapped enums to be written as int/string #3303

roji opened this issue Nov 8, 2020 · 5 comments · May be fixed by #4838
Assignees
@vonzshik
Labels
enhancement
Milestone
9.0.0

Comments

@roji
Copy link
Member

roji commented Nov 8, 2020

@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.
@roji roji added this to the vNext milestone Nov 8, 2020
@mikependon
Copy link

@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
Copy link
Contributor

#3389 changed the behaviour of the driver by allowing writing of unmapped enum without setting up a command parameter.

@roji
Copy link
Member Author

roji commented 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
Copy link

@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
Copy link
Member Author

roji commented 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).

@vonzshik vonzshik modified the milestones: 6.0.0, 7.0.0 Oct 3, 2021
@roji roji modified the milestones: 7.0.0, 8.0.0 Nov 1, 2022
@vonzshik vonzshik self-assigned this Dec 28, 2022
@vonzshik vonzshik linked a pull request Dec 28, 2022 that will close this issue
Open
@vonzshik vonzshik mentioned this issue Mar 27, 2023
Closed
This was referenced Aug 15, 2023
Closed
Closed
Closed
Closed
@roji roji removed the up for grabs label Nov 7, 2023
@NinoFloris NinoFloris modified the milestones: 8.0.0, 9.0.0 Nov 15, 2023
@NinoFloris NinoFloris mentioned this issue Feb 27, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vonzshik vonzshik

Labels
enhancement
Projects
None yet
Milestone
9.0.0
Development

Successfully merging a pull request may close this issue.

Add support for writing unknown unmapped enums as string and int npgsql/npgsql
5 participants
@mikependon @roji @NinoFloris @YohDeadfall @vonzshik