Quantcast
Channel: Entity Framework
Viewing all 10318 articles
Browse latest View live

Closed Issue: Upgrading EF 6.0.2 -> EF6.1.0 Create Indexes [2167]

$
0
0
After upgrading from EF 6.0.2 to 6.1.0 my database is no longer compatible with current model.
When adding a migration EF wants to create all indexes. I have worked around this by first deleting all indexes (took this code from the down method) and creating them.
This fixed the issue. Not sure if this is by design, i couldn't find an upgrade guide to 6.1.

Thought i'd let you know.

Closed Issue: Templates: Generated code should not produce FxCop errors [203]

$
0
0
Open the attached project and run code analysis on it. Based on your code analysis settings you will see some errors.

This item was migrated from the DevDiv work item tracking system [ID=368692].

Reviewed: EF 6.0.0 (dez 17, 2014)

$
0
0
Rated 4 Stars (out of 5) - teste teste teste

Commented Issue: Designer: Entity Framework randomly reorders imported function parameters for stored proc [705]

$
0
0
**Reactivating as we now have more details on this issue - see comments**

This item was ported from a public Connect issue - https://connect.microsoft.com/VisualStudio/feedback/details/757222/entity-framework-randomly-reorders-imported-function-parameters-for-stored-proc

Problem Description:
Example: I have a stored procedure (let's call it sp_X) that receives an int and a string parameter. I add it to my entity framework model and import it as a function. The function import correctly builds a method that receives an int as the first parameter, a string as the second. This will work for months -- even after adding additional new (unrelated) function imports to the model and rebuilding multiple times -- and then, randomly after adding some new object to the model and updating model from database, I'll get a compile error because the function for sp_X's int and string parameters have been flipped .... it's now sp_X(string, int). No changes have been made to the proc (sp_X). I have to remove the proc and function from the model and reload both in order to correct the problem -- but this flipping behavior will return randomly for this proc. I read recently that if I drop/recreate the proc the problem will be corrected long-term but this is not an ideal solution since, in the case of a stored procedure with string, string parameters, I won't get a compile error when they flip but I will get run-time issues because the function is now sending string 1 to the string 2 parameter and string 2 to the string 1 parameter. Note: I am currently using the Entity Framework 4.0.30319.
Comments: Thanks for re-opening. We've worked around the issue by using named parameters when calling the EDMX functions which has taken a fair amount of re-work. Since it sounds like it's still an issue in EF5 and EF6, I'm keen to try and help resolve. The database exhibiting the issue contains 218 tables, 149 views, 97 functions and 892 stored procedures. Our EDMX only contains 43 of the stored procedures; no tables, no views and no functions. I've been attempting to get you a backup of a cut-down sample database exhibiting this issue but have so far been unsuccessful. Unfortunately, I can't send you the problem database as as it belongs to a client. The EF model generation has been working fine for months and all the parameters were generated in the correct order.. then after recently modifying one of the 43 stored procedures the generation started jumbling the parameters up. This database is hosted on MS SQL Server 2005 SP3 (9.0.4035). I've tried restoring the database to a 2008 R2 server (10.50.4000) but the model generation still jumbles the parameters up. I'll attempt to get you some more information later this week. Let me know if I can provide anything else in the mean time.

Source code checked in, #5856e0826de7c40653fcf60d0da3fd625bbe6bcb

$
0
0
Fix for issue 2590. Revert changeset 6f4a59148c5c. I.e. remove interceptor that turned on DBCC 9481 flag. The flag could only be used by admin users and our queries have changed so the flag should no longer be necessary.

Edited Issue: Investigate impact of DBCC TRACEON [2590]

$
0
0
According to [this article](http://spaghettidba.com/2013/02/08/using-querytraceon-in-plan-guides/), there might be a potential permissions issue when a low-privileges account executes a query that uses a QUERYTRACEON option. For example:
```SQL
SELECT *
FROM [AdventureWorks2012].[Person].[Person]
OPTION (QUERYTRACEON 4199)
```
If the user doesn't have enough privileges then the following error will return from the server:
```
Msg 2571, Level 14, State 3, Line 1
User ‘guest’ does not have permission to run DBCC TRACEON.
```
This is worthy of investigation since [changeset 6f4a59148c5c](http://entityframework.codeplex.com/SourceControl/changeset/6f4a59148c5c980d42d61bcc594a2837a236ef6f) tried to fix workitem [2445](https://entityframework.codeplex.com/workitem/2445) by adding a QUERYTRACEON option to the process of discovering the store schema as a workaround given that SQL Server 2014 has a performance regression and this trace flag tells the engine to behave as SQL Server 2012 would for this query.

If this change affects users with low privileges negatively (meaning, they used to be able to obtain the store schema information but now can't) then we must address it as a compatibility issue.

Commented Issue: Investigate impact of DBCC TRACEON [2590]

$
0
0
According to [this article](http://spaghettidba.com/2013/02/08/using-querytraceon-in-plan-guides/), there might be a potential permissions issue when a low-privileges account executes a query that uses a QUERYTRACEON option. For example:
```SQL
SELECT *
FROM [AdventureWorks2012].[Person].[Person]
OPTION (QUERYTRACEON 4199)
```
If the user doesn't have enough privileges then the following error will return from the server:
```
Msg 2571, Level 14, State 3, Line 1
User ‘guest’ does not have permission to run DBCC TRACEON.
```
This is worthy of investigation since [changeset 6f4a59148c5c](http://entityframework.codeplex.com/SourceControl/changeset/6f4a59148c5c980d42d61bcc594a2837a236ef6f) tried to fix workitem [2445](https://entityframework.codeplex.com/workitem/2445) by adding a QUERYTRACEON option to the process of discovering the store schema as a workaround given that SQL Server 2014 has a performance regression and this trace flag tells the engine to behave as SQL Server 2012 would for this query.

If this change affects users with low privileges negatively (meaning, they used to be able to obtain the store schema information but now can't) then we must address it as a compatibility issue.
Comments: Fixed with changeset 5856e08. Reverted David's changeset 6f4a591 which fixed issue https://entityframework.codeplex.com/workitem/2445. As reported above that fix did not work for non-admin users and our queries have changed such that we no longer need that flag turned on anyway.

Source code checked in, #3bc6b269e3418f6166d0a367171824d674055b7c

$
0
0
Updating master branch version number to 6.1.3-alpha1 after creating release-6.1.2 branch.

Created Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of # 2560)
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>().HasRequired(c => c.B1).WithRequiredPrincipal();
modelBuilder.Entity<A>().HasRequired(c => c.B2).WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

For EF 6.1.2 we produce the following output:
minimumReproSql:
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC

complexReproSql:
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
In EF 6.1.1 and previous versions down to 5.0 the result was this:
minimumReproSql:
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC

complexReproSql:
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC

Edited Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of # 2560)
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
```
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>().HasRequired(c => c.B1).WithRequiredPrincipal();
modelBuilder.Entity<A>().HasRequired(c => c.B2).WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

```
For EF 6.1.2 we produce the following output:

```
minimumReproSql:
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC
```

```
complexReproSql:
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
```

In EF 6.1.1 and previous versions down to 5.0 the result was this:
minimumReproSql:
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
complexReproSql:
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC

Edited Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of # 2560)
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
```
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>().HasRequired(c => c.B1).WithRequiredPrincipal();
modelBuilder.Entity<A>().HasRequired(c => c.B2).WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

```
For EF 6.1.2 we produce the following output:

```
minimumReproSql:
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC
```

```
complexReproSql:
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
```

In EF 6.1.1 and previous versions down to 5.0 the result was this:
minimumReproSql:
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
complexReproSql:
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```

Edited Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of # 2560)
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
```
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>().HasRequired(c => c.B1).WithRequiredPrincipal();
modelBuilder.Entity<A>().HasRequired(c => c.B2).WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

```
For EF 6.1.2 we produce the following output:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC
```

__complexReproSql:__

```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
```

In EF 6.1.1 and previous versions down to 5.0 the result was this:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
__complexReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```

Edited Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of # 2560)
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
```
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>()
.HasRequired(c => c.B1)
.WithRequiredPrincipal();
modelBuilder.Entity<A>()
.HasRequired(c => c.B2)
.WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

```
For EF 6.1.2 we produce the following output:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC
```

__complexReproSql:__

```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
```

In EF 6.1.1 and previous versions down to 5.0 the result was this:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
__complexReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```

Edited Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of # 2560)
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
```
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>()
.HasRequired(c => c.B1)
.WithRequiredPrincipal();
modelBuilder.Entity<A>()
.HasRequired(c => c.B2)
.WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

```
For EF 6.1.2 we produce the following output:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC
```

__complexReproSql:__

```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
```

In EF 6.1.1 and previous versions down to 5.0 the result was this:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
__complexReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
It is possible that there are simpler repros (e.g. with just one navigation property it is possible to repro) but I

Edited Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of # 2560)
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
```
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>()
.HasRequired(c => c.B1)
.WithRequiredPrincipal();
modelBuilder.Entity<A>()
.HasRequired(c => c.B2)
.WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

```
For EF 6.1.2 we produce the following output:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC
```

__complexReproSql:__

```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
```

In EF 6.1.1 and previous versions down to 5.0 the result was this:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
__complexReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
Note that it is possible that there are simpler repros (e.g. with just one navigation property) but I wanted to show how the problem composes when you have more. it is possible to repro) but I

Edited Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of [#2560](https://entityframework.codeplex.com/workitem/2560))
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
```
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>()
.HasRequired(c => c.B1)
.WithRequiredPrincipal();
modelBuilder.Entity<A>()
.HasRequired(c => c.B2)
.WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

```
For EF 6.1.2 we produce the following output:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC
```

__complexReproSql:__

```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
```

In EF 6.1.1 and previous versions down to 5.0 the result was this:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
__complexReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
Note that it is possible that there are simpler repros (e.g. with just one navigation property) but I wanted to show how the problem composes when there is more complexity.

Created Unassigned: Constraints don't get dropped after table is renamed [2613]

$
0
0
We had an entity with several relations.
After a couple migrations it was decided to rename the table.
Eventually, a migration was required to change a 1-1-relation to a 1-*-relation.
This is where we encountered an issue.
Entity framework was unable to drop the existing foreign key constraint, because the name still contained the old table's name, rather than the new one.


Commented Unassigned: Query: Regression in EF 6.1.2: OUTER APPLY introduced and more compex queries for 1:1 relationships and "let" clause [2612]

$
0
0
(found this modifying the repro of [#2560](https://entityframework.codeplex.com/workitem/2560))
The code below produces more complex queries than before and introduces OUTER APPLY when it wasn’t necessary from EF 5.0 to EF 6.1.1. It seems that some of the query improvements we made removed the ability to simplify it.
```
using System;
using System.Data.Entity;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new BugContext())
{
context.Database.Delete();

var minimumReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
select new
{
c.Id,
Rel1 = new
{
c.B1.Id,
c.B1.Code,
}
};

var complexReproLinq =
from c in context.As.OrderBy(c => c.Id).Take(100)
let rel1 = c.B1
let rel2 = c.B2
select new
{
c.Id,
Rel1 = new
{
rel1.Id,
rel1.Code,
},
Rel2 = new
{
c.B2.Id,
c.B2.Code,
}
};

var minimumReproSql = minimumReproLinq.ToString();
var complexReproSql = complexReproLinq.ToString();
Console.WriteLine(minimumReproSql);
Console.WriteLine(complexReproSql);

}
}
}

public class BugContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<A>()
.HasRequired(c => c.B1)
.WithRequiredPrincipal();
modelBuilder.Entity<A>()
.HasRequired(c => c.B2)
.WithRequiredPrincipal();
}

public DbSet<A> As { get; set; }
public DbSet<B> Bs { get; set; }
}

public class A
{
public int Id { get; set; }
public virtual B B1 { get; set; }
public virtual B B2 { get; set; }
}

public class B
{
public int Id { get; set; }
public string Code { get; set; }
}
}

```
For EF 6.1.2 we produce the following output:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Filter2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Code] AS [Code]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
ORDER BY [Extent1].[Id] ASC
```

__complexReproSql:__

```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code],
[Filter6].[Code1] AS [Code1]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
OUTER APPLY (SELECT [Extent3].[Id] AS [Id1]
FROM [dbo].[B] AS [Extent3]
LEFT OUTER JOIN (SELECT
[Extent4].[Id] AS [Id]
FROM [dbo].[B] AS [Extent4]
WHERE [Extent1].[Id] = [Extent4].[Id] ) AS [Project1] ON 1 = 1
WHERE [Extent1].[Id] = [Extent3].[Id] ) AS [Filter2]
OUTER APPLY (SELECT [Extent5].[Code] AS [Code1]
FROM [dbo].[B] AS [Extent5]
LEFT OUTER JOIN (SELECT
[Extent6].[Id] AS [Id]
FROM [dbo].[B] AS [Extent6]
WHERE [Extent1].[Id] = [Extent6].[Id] ) AS [Project2] ON 1 = 1
LEFT OUTER JOIN (SELECT [Extent7].[Id] AS [Id2]
FROM [dbo].[B] AS [Extent7]
LEFT OUTER JOIN (SELECT
[Extent8].[Id] AS [Id]
FROM [dbo].[B] AS [Extent8]
WHERE [Extent1].[Id] = [Extent8].[Id] ) AS [Project3] ON 1 = 1
WHERE [Extent1].[Id] = [Extent7].[Id] ) AS [Filter5] ON 1 = 1
WHERE [Extent1].[Id] = [Extent5].[Id] ) AS [Filter6]
ORDER BY [Extent1].[Id] ASC
```

In EF 6.1.1 and previous versions down to 5.0 the result was this:

__minimumReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
__complexReproSql:__
```
SELECT TOP (100)
[Extent1].[Id] AS [Id],
[Extent2].[Id] AS [Id1],
[Extent2].[Code] AS [Code]
FROM [dbo].[A] AS [Extent1]
LEFT OUTER JOIN [dbo].[B] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Id]
ORDER BY [Extent1].[Id] ASC
```
Note that it is possible that there are simpler repros (e.g. with just one navigation property) but I wanted to show how the problem composes when there is more complexity.
Comments: Looks like this could be the same or similar tohttps://entityframework.codeplex.com/workitem/2413.

Commented Unassigned: EF6 DDL For LocalDB Has USE pointing to invalid Database [2476]

$
0
0
When EF generates the DDL for a LocalDB file connection it generates a DDL that has a use statement like:

```
USE [MyDatabaseName]
GO

```
This is wrong and when you try to execute it can't find the database, because that is the wrong format for the USE keyword and LocalDB files. What I had to change it to, to allow it to work with a USE:

```
USE [C:\MyPathToDatabase\MyDatabase.mdf]
GO
```

This works, and code complete in VS2013 will allow you to select it after typing the open bracket.

The other workaround is to comment out those two lines and make sure you select the LocalDB from the dropdown in Visual Studio 2013 and then execute. However this method is risky as it requires a human to remember to select the right one.

Also having to hardcode a full path kind of sucks, and makes it less portable not sure how to make it more dynamic based on limitations of embedded file based DB's like LocalDB.


Comments: What do you mean "we don't generate a use for scripts" if you are not generating it then what or who is? Also this is use the designer to design the models and then have it generate the database. There was no database yet. This was design first. Since the DB does not exist yet you have to use the FILE name. If the DB did exist and was registered as a named DB then the use will work with just the DB name otherwise you have to use the file name. Regardless I moved on long time ago so I don't really care if you choose to fix this or not, I was just letting you guys know about it. Because of this, I switched to Code-First and have been happy ever since and have had no major issues.

Created Issue: Unblock Code First model conventions from creating Model Defined Functions [2615]

$
0
0
Currently model defined functions cannot be created using Code First model conventions. Unblocking this would enable such things as @moozzyk's [Code First Functions](https://codefirstfunctions.codeplex.com/) project to defined model defined functions, as explained in the comments in [#2485](http://entityframework.codeplex.com/workitem/2485).

I started digging into why this is blocked with the following convention that attemps to produce a (not very useful) model defined function:

```
public class StuffFunctionInjectionConvention :
IConceptualModelConvention<EdmModel>
{
public void Apply(EdmModel item, DbModel model)
{
FunctionParameter parameter = FunctionParameter.Create(
"birthDate",
PrimitiveType.GetEdmPrimitiveType(PrimitiveTypeKind.DateTime),
ParameterMode.In);

FunctionParameter returnValue = FunctionParameter.Create(
"result",
PrimitiveType.GetEdmPrimitiveType(PrimitiveTypeKind.Int32),
ParameterMode.ReturnValue);

EdmFunction function = item.CreateAndAddFunction(
"GetAge",
new[] {parameter},
new[] {returnValue},"SELECT 5"); // TODO: calculate
}
}

public static class DbMetadataExtensions
{
public static EdmFunction CreateAndAddFunction(this EdmModel item, string name,
IList<FunctionParameter> parameters, IList<FunctionParameter> returnValues, string body = null)
{
var payload = new EdmFunctionPayload
{

StoreFunctionName = name,
Parameters = parameters,
ReturnParameters = returnValues,
Schema = item.GetDefaultSchema(),
CommandText = body

};

EdmFunction function = EdmFunction.Create(
name,
item.GetDefaultNamespace(),
item.DataSpace, payload,
null);

item.AddItem(function);

return function;
}

public static string GetDefaultNamespace(this EdmModel layerModel)
{
return layerModel
.GlobalItems
.OfType<EdmType>()
.Select(t => t.NamespaceName)
.Distinct()
.Single();
}

public static string GetDefaultSchema(this EdmModel layerModel)
{
return layerModel
.Container
.EntitySets
.Select(s => s.Schema)
.Distinct()
.SingleOrDefault();
}
}

```

The first thing I hit is the following validation errors:

Schema specified is not valid. Errors:
(0,0) : error 0005: The 'Aggregate' attribute is not allowed.
(0,0) : error 0005: The 'BuiltIn' attribute is not allowed.
(0,0) : error 0005: The 'NiladicFunction' attribute is not allowed.
(0,0) : error 0005: The 'IsComposable' attribute is not allowed.
(0,0) : error 0005: The 'ParameterTypeSemantics' attribute is not allowed.
(0,0) : error 0005: The 'Schema' attribute is not allowed.
(0,0) : error 0005: The 'Mode' attribute is not allowed.

Furthermore, the DefiningExpression element that is required for model defined functions is currently not honored by the EDM serialization code (e.g. in EdmModelVisitor & EdmSerializationVisitor; historically neither Code First nor the EF Designer used them).

Viewing all 10318 articles
Browse latest View live




Latest Images