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

RelationalMethodCallTranslatorProvider and explicit typeMapping #27524

Closed
mm3141 opened this issue Mar 1, 2022 · 2 comments · Fixed by #27995
Closed

RelationalMethodCallTranslatorProvider and explicit typeMapping #27524

mm3141 opened this issue Mar 1, 2022 · 2 comments · Fixed by #27995
Assignees
Labels
area-query closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported type-bug
Milestone

Comments

@mm3141
Copy link

mm3141 commented Mar 1, 2022

Hi,
is it on purpose that dbFunction.TypeMapping is not passed in into these calls, but the default null is used?

return dbFunction.IsBuiltIn
? _sqlExpressionFactory.Function(
dbFunction.Name,
arguments,
dbFunction.IsNullable,
argumentsPropagateNullability,
method.ReturnType.UnwrapNullableType())
: _sqlExpressionFactory.Function(
dbFunction.Schema,
dbFunction.Name,
arguments,
dbFunction.IsNullable,
argumentsPropagateNullability,
method.ReturnType.UnwrapNullableType());

We have some SQL function returning string[], and have to use HasDbFunction with a more complex HasTranslation instead of the simple fluent API, presumably because of this.

@smitpatel
Copy link
Contributor

Currently, the TypeMapping on DbFunction is not set by anything. It is derived when accessing based on store type string specified. This means that the store type must be mappable by the provider for given CLR type returned by function. There is no way to specify a value converter for DbFunctions yet. So the CLR type has to be mappable by provider for this to work correctly in all path (till we get value converter support). If the CLR type can be mapped to multiple different store type then store type string helps figuring out the correct one.

Passing in the type mapping here will help with inferring the type mapping. Currently user set type mapping is ignored other than validating that it is mappable type.

@smitpatel smitpatel assigned smitpatel and unassigned maumar May 10, 2022
@smitpatel
Copy link
Contributor

Poaching

@smitpatel smitpatel added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label May 10, 2022
smitpatel added a commit that referenced this issue May 10, 2022
- Add a convention which configures actual type mapping from store type on DbFunction
- While translating db function use the TypeMapping if available

Resolves #27954
Resolves #27524
smitpatel added a commit that referenced this issue May 11, 2022
- We use TypeMapping if configured on the DbFunction, or
- We try to get it if store type is specified
- If neither of above work then we do the default type mapping based on return type

Resolves #27954
Resolves #27524
smitpatel added a commit that referenced this issue May 11, 2022
@ajcvickers ajcvickers modified the milestones: 7.0.0, 7.0.0-preview5 May 25, 2022
smitpatel added a commit that referenced this issue Sep 27, 2022
@ajcvickers ajcvickers modified the milestones: 7.0.0-preview5, 6.0.12 Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-query closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported type-bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants