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.

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

Enable value conversion support for identity/sequence properties #25178

Merged
merged 3 commits into from
Aug 5, 2021

Conversation

lauxjpn
Copy link
Contributor

@lauxjpn lauxjpn commented Jun 30, 2021

Allows to use value converters for identity and sequence columns, within the limitations already established (must be a non-floating point numerical type on the provider side).

Implements PomeloFoundation/Pomelo.EntityFrameworkCore.MySql#1118 for SQL Server.

I added an explicit .UnwrapNullableType() call, so that a decimal? would behave the same way as an int? (both are not really supported for identity columns by SQL Server, but they should at least be handled in the same way before SQL Server finally returns an error, and should not lead to different behavior in EF Core).
It would probably be cleaner to check for non-nullable types only in general instead.

Related to #11597 and npgsql/efcore.pg#1439

I don't see any issues with this PR in regards to #11597.
If there are, feel free to add a test or two to demonstrate those.

@lauxjpn lauxjpn changed the title Add value conversion support for identity/sequence properties Enable value conversion support for identity/sequence properties Jun 30, 2021
@AndriySvyryd AndriySvyryd self-assigned this Jul 6, 2021
@AndriySvyryd
Copy link
Member

Could you also add a test (or modify an existing one) that actually inserts a row with Identity and a converter?

@AndriySvyryd
Copy link
Member

If you remove the check for all types of store-generation, we'll also need tests for sequences, default values and computed columns. As well as a variety of store/client type combinations. This will also need a review from @ajcvickers when he's back, to make sure this is in-line with #11597 and #11970

@ajcvickers
Copy link
Member

I think this is probably okay; I can't think of a way it will break after a more general solution. I'm inclined to take this; we will discuss again next triage.

@AndriySvyryd
Copy link
Member

Thanks for your contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants