(I am filing this bug as part of investigating issue [#825](http://entityframework.codeplex.com/workitem/825). I think this is probably a future feature with high or medium priority given it is a common request)
Customers often want to express a query that brings a set of entities and their children but only when the children's exist. In SQL (and even in Entity SQL) it is very easy to express with an INNER JOIN operation. In LINQ, and in particular in LINQ to Entities, this is surprisingly difficult.
Here are two common patterns that people can use today and are semantically equivalent to INNER JOIN in LINQ:
```
var owners1 = db.People
.Where(p => p.Belongings.Any())
.Include(p => p.Belongings);
var owners2 = db.People
.Where(p => p.Belongings.Count() > 0)
.Include(p => p.Belongings);
```
The first thing we could consider is recognizing patterns like these and translate and collapsing them into queries with INNER JOIN. Currently we translate these kind of queries literarily and we produce LEFT OUTER JOINS (because of the Includes) with additional WHERE clauses, but unfortunately these produce query execution plans on the database that can be often much less efficient than the equivalent query using INNER JOIN.
Another interesting option would be to introduce a specific query operator that would allow to express the same semantics as the Include but with added constrain that it has to satisfy the INNER JOIN, e.g.:
```
var owners3 = db.People.Having(p => p.Belongings);
```
Comments: Dennis, the Join operator in LINQ does in fact represent INNER JOIN and is supported by LINQ to Entities. But it requires matching two values on both sides and using quite a bit of syntax (I know many people that keep forgetting what the syntax is :) ). Navigation properties should make things easier but they don't because in most cases they have the semantics of LEFT OUTER JOINs. Thanks for your feedback, I have updated the title to clarify what the point is and I am going to be updating the text with more examples of what is supported and what we could support in the future.
Customers often want to express a query that brings a set of entities and their children but only when the children's exist. In SQL (and even in Entity SQL) it is very easy to express with an INNER JOIN operation. In LINQ, and in particular in LINQ to Entities, this is surprisingly difficult.
Here are two common patterns that people can use today and are semantically equivalent to INNER JOIN in LINQ:
```
var owners1 = db.People
.Where(p => p.Belongings.Any())
.Include(p => p.Belongings);
var owners2 = db.People
.Where(p => p.Belongings.Count() > 0)
.Include(p => p.Belongings);
```
The first thing we could consider is recognizing patterns like these and translate and collapsing them into queries with INNER JOIN. Currently we translate these kind of queries literarily and we produce LEFT OUTER JOINS (because of the Includes) with additional WHERE clauses, but unfortunately these produce query execution plans on the database that can be often much less efficient than the equivalent query using INNER JOIN.
Another interesting option would be to introduce a specific query operator that would allow to express the same semantics as the Include but with added constrain that it has to satisfy the INNER JOIN, e.g.:
```
var owners3 = db.People.Having(p => p.Belongings);
```
Comments: Dennis, the Join operator in LINQ does in fact represent INNER JOIN and is supported by LINQ to Entities. But it requires matching two values on both sides and using quite a bit of syntax (I know many people that keep forgetting what the syntax is :) ). Navigation properties should make things easier but they don't because in most cases they have the semantics of LEFT OUTER JOINs. Thanks for your feedback, I have updated the title to clarify what the point is and I am going to be updating the text with more examples of what is supported and what we could support in the future.