-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Fix to #30244 - Json column fails to materialize only when default interceptor used #30403
Conversation
test/EFCore.Relational.Specification.Tests/Query/JsonQueryAdHocTestBase.cs
Outdated
Show resolved
Hide resolved
…terceptor used Problem was that when we build materializer expression, ValueBufferTryReadValue call that extracts values of keys is typed with key's CLR type. This fails for json as we visit the materializer expression, because calls to ValueBufferTryReadValue are replaced with array accesses to object[] that we store key values in. We should be using ValueBufferTryReadValue<object> when trying to get value for keys, like we do everywhere else, so that after the visitation expression types are correct. Fixes #30244
@maumar I moved the testing to the interceptor tests, which are setup to handle this. |
@@ -25,5 +43,8 @@ protected override ITestStoreFactory TestStoreFactory | |||
IServiceCollection serviceCollection, | |||
IEnumerable<ISingletonInterceptor> injectedInterceptors) | |||
=> base.InjectInterceptors(serviceCollection.AddEntityFrameworkSqlite(), injectedInterceptors); | |||
|
|||
public override DbContextOptionsBuilder AddOptions(DbContextOptionsBuilder builder) | |||
=> base.AddOptions(builder.ConfigureWarnings(e => e.Ignore(SqliteEventId.CompositeKeyWithValueGeneration))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maumar Had to suppress his warning, which I don't think should apply when the owned type is mapped to JSON. Are we tracking this somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#26708, but maybe we need something json specific?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will people get this warning if they explicitly configure a composite key for a mapped JSON collection when that configuration is valid? /cc @AndriySvyryd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will people get this warning if they explicitly configure a composite key for a mapped JSON collection when that configuration is valid?
Yes, unless they mark the non-fk property as never generated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maumar Given Andriy's response, I think we need a new issue for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Problem was that when we build materializer expression, ValueBufferTryReadValue call that extracts values of keys is typed with key's CLR type. This fails for json as we visit the materializer expression, because calls to ValueBufferTryReadValue are replaced with array accesses to object[] that we store key values in. We should be using ValueBufferTryReadValue when trying to get value for keys, like we do everywhere else, so that after the visitation expression types are correct.
Fixes #30244