Property defining expressions for query: mapping model properties to non-column expressions

Open
#10,768 14 comments 12 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
csharp, sql
Domain
databases

Research direction

Start with the FromSql query path and the existing NotMappedAttribute behavior described in the issue, then trace how model properties are mapped to result-set columns and schema migrations. Define how a dynamically mapped property should behave when its calculated result column is present or absent, without creating or storing a schema column. Done means the behavior is specified and covered for querying, migrations, and saving.

Written by the indexing model from the issue text.

Description

area-query area-relational-mapping

Certain search strategies (full text search, spatial search, ...) leverage underlying database tech for better indexing and retrieval.

Scenario: I have "latitude" and "longitude" columns in my schema. I would like to map a property "Distance" to a column in the result set that evaluates the distance between those coordinates and user coordinates, i.e. SQL like:

SELECT 
    [latitude], 
    [longitude], 
    calculate_distance(latitude, longitude, @user_latitude, @user_longitude) AS [Distance]
FROM coordinates;

The easiest way to do this is to add a Distance to the model as an always NULL column, and then use context.Coordinates.FromSql("...", sqlParametes) when querying. The downside is that this creates an extraneous column in the schema. (I was hoping I could use NotMappedAttribute but that obviously also suppresses value mapping when querying).

As a workaround, I have to do the following steps:

  1. Manually drop the columns in a migration script
  2. Set Property("Distance").Metadata.BeforeSaveBehaviour and Property("Distance").Metadata.BeforeSaveBehaviour to PropertySaveBehaviour.Ignore
  3. Ensure that all queries return a result set with a calculated [Distance] column, to satisfy EF's assumption that there is one.

A better approach would be to have something like [DynamicallyMappedAttribute] - similar to [NotMappedAttribute], it suppresses column creation and value storage, but has a different value retrieval behaviour - i.e. when querying I would like for EF to tolerate it these properties are not present as a column in the result set. Map them when they are there and if not, just set them to NULL.

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.