Support (custom) member/method translations on value-converted types

Open
#10,434 46 comments 157 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
csharp, sql
Domain
backend-api-design, database

Research direction

Start by reading the SQL translation scenario in #10427 and the discussion on this issue. The short-term target is a defined fallback to client evaluation for value-converted properties; the longer-term outcome is for type mappings and value conversions to participate in translation generation.

Written by the indexing model from the issue text.

Description

area-o/c-mapping area-query needs-design

Consider cases like #10427 which involves SQL translations for DateTime calculations. If the property has been mapped to some non-datetime type, then this kind of translation will not work anymore. Instead, query should either:

  • Do a different translation
  • Revert to client evaluation

Probably client eval is what we can realistically do in the short term, but in the future it would be good to have the type mapping/value conversion participate in generating the translations.

Dominant language
C#
Stars
14.8k
Forks
3.4k
Avg merge
2d 5h
Merged PRs (30d)
134

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/efcore

All issues in dotnet/efcore

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.