Query: Number is written into SQL Command Text instead of being a parameter when using 'this'

[Wain123]

ctx.Blogs.Where(b => b != this).Count();

Gets translated to:

SELECT COUNT(*)
FROM "BLOGS" "b"
WHERE "b"."SEQNR" <> 532732.0

EF Core version: 2.1.0-rc1-30677
Database Provider: Microsoft.EntityFrameworkCore.Oracle
Operating system: Windows 10
IDE: Visual Studio Professional 2017 15.6.5

[ajcvickers]

@Wain123 So this is a Blog instance? And is your expectation that if a new Blog is created later and this query is run again it will use the ID of the new Blog, not the one on which the query was created?

[smitpatel]

this is Expression.Constant of blog in ExpressionTree

[Wain123]

@ajcvickers Yes, this is a Blog instance. No, I expect that I can run the query anywhere (in a different Blog or outside of a Blog) and the this would still refer to the original Blog that created the query. I expect this to be treated the same way as any other reference to an entity.

So, I expect it to behave the same as the following code:

var a = this;
ctx.Blogs.Where(b => b != a).Count();

Which means it would translate to:

SELECT COUNT(*)
FROM "BLOGS" "b"
WHERE "b"."SEQNR" <> :a_0_Seqnr

The only difference would be that the constant ID value is in a parameter instead of the command text, which is usually a good idea (at least, I think there's a reason why you do that for most queries).

The reason why I expect this is because of this example:

public class Foo {
	public Action f() {
		return () => Console.WriteLine(this);
	}
}

I can write new Foo().f().Invoke() anywhere, even inside a static method, and it will output "Foo", not the name of the object that called it. So, it's possible to capture this just like a normal variable.

[ajcvickers]

We discussed this at length in triage and decided that as of now we will leave this behavior as is. While this is a case where parameterizing makes sense it is a very limited and unusual scenario and it is not clear that in general parameterizing constants from the expression tree is desirable. Also, the ultimate behavior will be the same and the workarounds to allow this parameterization (for example, using key comparisons directly) are not unreasonable. Finally, special casing this adds complexity to query and increases the test matrix, which is something that we want to avoid in the query pipeline. If we hear more cases like this, then we may reconsider this decision.