Query: Comparing same reference navigation can converted to comparison on parent

[smitpatel]

for comparison like o1.Customer == o2.Customer can be converted to o1.Id == o2.Id iff Customer navigation is dependent to principal and required.

[Wain123]

This would be made unnecessary if #8480 gets implemented.

[smitpatel]

@Wain123 - They are totally different issues. This optimization has nothing to with lazy loading in any form what-so-ever. Further, not everyone uses lazy loading.

[Wain123]

@smitpatel I might be misunderstanding this issue then, please clarify what I'm seeing wrong. The way I understand this issue is:
The comparison o1.Customer == o2.Customer might be computationally expensive because it goes over navigation properties and entities, so you want to do the comparison using only keys instead.

If that understanding is correct, then it is more-or-less a special case of #8480, which asks to replace many kinds of entity operations with key operations.

[smitpatel]

@Wain123 - o1.Customer == o2.Customer is already converted to equality on their PK property values of Customers. This specific issue tracks the optimization which we can just use equality on Orders and not even worry about fetching PK properties of Customers (That avoids join with Customer table in SQL hence optimization). Though this is specifically query time processing. We do all above (and optimization in future), if the expression appears in a linq query you are running in EF Core which will translate to SQL.

#8480 is about using proxy to compare navigation equality to key equality on client side. More specifically out of the context of linq query. Or at least the linq query which won't be translated to server.

[Wain123]

@smitpatel Oh, I didn't realize this issue was specifically talking about translated queries. The "Query:" in the title should have been a hint. Sorry.

[smitpatel]

Consider this in #20164