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

Query: consider expanding null safety beyond nav rewrite #12284

Closed
AlekseyMartynov opened this issue Jun 7, 2018 · 4 comments
Closed

Query: consider expanding null safety beyond nav rewrite #12284

AlekseyMartynov opened this issue Jun 7, 2018 · 4 comments
Labels
closed-out-of-scope This is not something that will be fixed/implemented and the issue is closed. customer-reported type-enhancement

Comments

@AlekseyMartynov
Copy link

Version: 2.1.1-rtm-30843 (nightly build)

Please consider this example:

Entity:

public class TestEntity {
    public int ID { get; set; }
    public DateTime? Date { get; set; }
}

Ensure there are records:

var set = context.Set<TestEntity>();
set.Add(new TestEntity());
context.SaveChanges();

Now, this is a query that is fully translated into SQL:

var result = set
    .GroupBy(obj => new {
        Year = (int?)obj.Date.Value.Year
    })
    .Select(g => new {
        g.Key.Year,
        Count = g.Count()
    })
    .ToArray();
SELECT DATEPART(year, [obj].[Date]) AS [Year], COUNT(*) AS [Count]
FROM [TestEntity] AS [obj]
GROUP BY DATEPART(year, [obj].[Date])

However, if I modify it as follows:

var result = set
    .GroupBy(obj => new {
        Year = (int?)obj.Date.Value.Year
    })
    .Select(g => new {
        g.Key.Year,
        Count = g.Count(i => i.Date != null) // change here: count only non-null dates
    })
    .ToArray();

then it is partially translated into SQL:

SELECT [obj].[ID], [obj].[Date]
FROM [TestEntity] AS [obj]
ORDER BY DATEPART(year, [obj].[Date])

but grouping is done in-memory.

It fails with Nullable object must have a value.

I understand that for LINQ 2 Objects I would have to add null-conditional:

Year = obj.Date == null ? null : (int?)obj.Date.Value.Year

Finally the question:

Should the user of EF Core proactively take care of null safety as with L2O? Or on the contrary it is a bug and EF Core in-memory magic must hide it from me?

@ajcvickers
Copy link
Contributor

We do perform some re-writing already to cover some similar cases. We will consider enhancing this for 3.0.

@ajcvickers ajcvickers added this to the 3.0.0 milestone Jun 8, 2018
@divega divega changed the title Question regarding the necessity of null checks depending on in-memory or SQL evaluation Query: consider expanding null safety beyond nav rewrite Aug 3, 2018
@smitpatel
Copy link
Contributor

In the absence of client eval, this may not provide much value.

@AlekseyMartynov
Copy link
Author

@smitpatel

In the absence of client eval, this may not provide much value.

Yes, this ticket is about cases where a query is executed partially in SQL and partially in memory.
Are you planning to drop client evaluation in 3.0?

@smitpatel
Copy link
Contributor

smitpatel commented Jan 25, 2019

Are you planning to drop client evaluation in 3.0?

Brief answer, we are dropping it for most cases.
I will post long answer on #12795 soon.

@ajcvickers ajcvickers removed this from the 3.0.0 milestone Feb 6, 2019
@smitpatel smitpatel removed their assignment Jan 12, 2022
@ajcvickers ajcvickers added the closed-out-of-scope This is not something that will be fixed/implemented and the issue is closed. label Mar 10, 2022
@ajcvickers ajcvickers reopened this Oct 16, 2022
@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-out-of-scope This is not something that will be fixed/implemented and the issue is closed. customer-reported type-enhancement
Projects
None yet
Development

No branches or pull requests

4 participants