Unexpected null handling differences compared to EfCore

[npbenjohnson]

This probably isn't a bug, but it does make migrating a project from EfCore much more error prone. In queries that EfCore allows nullability to auto-compare, DbToLinq will optimize away the statement, which can have major effects if the query is used for Update(IQueryable) or Delete(IQueryable).

Example:

int? test = 1;
// This will return any records where MemberThatIsAnInt = 1
dbContext.Where(x => x.MemberThatIsAnInt == test).ToArray();
// This will never return any records because it will get optimized away to 1 = 0 in the sql
dbContext.Where(x => x.MemberThatIsAnInt == test).ToLinqToDB().ToArray();
// Workaround
// This will never return any records because it will get optimized away to 1 = 0 in the sql
dbContext.Where(x => x.MemberThatIsAnInt == test.Value).ToLinqToDB().ToArray();

I think this is expected behavior in LinqToDb since LinqToDB.Sql.AsNullable is available to deal with this kind of situation, it just makes it harder to convert existing EfCore because I have to manually comb through all of the nullability in all of the queries in the app, so if the default behavior when using a DbContext could match EfCore it would be really helpful. Also it might be worth noting it as part of the requirements for migrating a project in the FAQs.

[sdanyliv]

Strange, will try to reproduce.