Entity Framework join nullable join columns

2.6k views Asked by At

My Devart Entity Framework provider takes the following linq to entities.

from p in context.BEAT_CONTACT
join cl in context.COMPASS_LOCATIONS
on p.GAZETEER_KEY equals cl.GAZETTEER_KEY
//on new { bcdid = p.GAZETEER_KEY.Value }
//equals new { bcdid = cl.GAZETTEER_KEY.Value }
into myRandomlj
from rr in myRandomlj.DefaultIfEmpty()

Note: The join columns are nullable types in the DB and hence decimal? in c#

The generated SQL is:

FROM   NP_TEST.BEAT_CONTACT "Extent1"
LEFT OUTER JOIN NOTTS_DW_OWNER.COMPASS_LOCATIONS "Extent2"
ON ("Extent1".GAZETEER_KEY = "Extent2".GAZETTEER_KEY) 
* OR (("Extent1".GAZETEER_KEY IS NULL) 
* AND ("Extent2".GAZETTEER_KEY IS NULL))

The starred (*) OR and AND are adding extra seconds onto the execution of my sql. When the statement is placed into toad (oracle devart ef provider btw) with the starred items rem'd out the sql obviously runs a lot quicker.

My question is: Is my linq to entities at fault or missing something? Or is the fault with the Devart EF provider?

Update to Question: Hello as the original creator of this question i would like to try and get some clarity on the issue if possible. From LukLed's comments - "Default Entity Framework providers work correctly and don't create such SQL conditions. It is not only wrong, it is also a huge performance hitter". I am mainly concerned about the "performance hitter" comment, this hit is massive especially as the number of rows climb in either side of the join. I have had to circumvent this behaviour with ExecuteStoreQuery<> or Sproc. This has meant no linq and i have had to put on my sql hat to get the job done.

2

There are 2 answers

0
Devart On

@K Ivanov, you are correct. The case of two nulls should be taken into account as well, and the starred clauses do the trick.

8
Kris Ivanov On

that is perfectly fine, works as expected, the extra conditions make sure join on when both are null due to the fact that null = null is not true in SQL