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

Source code checked in, #999ad41ec03d9cc36cae3167e58d252b23985252

0
0
Changing version to 6.1.2-beta1

Commented Unassigned: EntityTypeConfiguration needs Indexing [2492]

0
0
I want to be able to create an index on a column.
I also want to be able to specify the index (clusted/non-clustered) on the primary key.

The TableBuilder already has these capabilities but there is no way through fluent API (EntityTypeConfiguration) to set these indexes.

I am using DbMigrations and have to remember to set these up manually for new tables.
Comments: Item is closed as Dupe, correctly so. Fejesjoco, as I stated in the dupe, the IndexAttribute property for Clustered is not used for some reason. No matter how I try, I cannot get my migration to set the clustering to false.

Source code checked in, #cc43b34032eddd4c97278657518a0b67aba7df0e

0
0
Updating version on master to 6.1.2-beta2

Edited Unassigned: Revisit usage of (localdb)\v11.0 in ProductivityAPI tests [2505]

0
0
See change #0079b18. In it I reverted some changes I'd put in to get several tests in the 2 test classes DatabaseTests.cs and SimpleScenariosForLocalDb.csto make them work on VS14. The problem was that on VS14 the version of localdb that comes with VS is referred to using "(localdb)\MSSQLLocalDB" whereas previously it was "(localdb)\v11.0".

Unfortunately the "fix" actually broke on the CI machine (which has VS2012 installed) as it depended on the MSBuild variables VS11, VS12 etc. Those build variables are not defined on a runtime build - hence the need to revert.

We don't want to produce different versions of the runtime

But those tests will still fail on a VS14 box. So we need to find a way to update the code appropriately.

Note that these changes were only in the test code - so it _may_ be OK to set up to depend on those environment variables for the test build only. But note from avickers: "we do not want people to have to change the current way they build - so it should default to something reasonable if no environment variable is set."

Perhaps set up a new env var e.g. EF6LocalDBName whose value can be v11.0 or MSSQLLocalDB and which defaults to v11.0 if not set? Then we can change the VS14 build to set that env var.

Closed Issue: getting "entity types cannot share table" for same-named tables in different schemas [1641]

0
0
I pulled CF DbContext classes recently created from EF PowerTools 0.7.0.0 in a VS2012/EF 5.0.0 project into a brand new EF 6.0.0-rc1 project. The app worked fine in EF 5.0.0. Now when I attempt to use the DbContext in EF 6.0.0-rc1 I get the "entity types cannot share table" error (even though the fluent configuration for the classes specify the correct ToTable mappings).

Here is a simplified repro:

```
namespace ConsoleApplication17
{
public class HREmployee
{
public int Id { get; set; }
}

public class Employee
{
public int Id { get; set; }
}

public partial class Bug1641Context : DbContext
{
public DbSet<HREmployee> Employees { get; set; }
public DbSet<Employee> NonHREmployees { get; set; }

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<HREmployee>().ToTable("Employee", "hr");
modelBuilder.Entity<Employee>().ToTable("RegularEmployees");
}
}

class Program
{
static void Main(string[] args)
{
using (var ctx = new Bug1641Context())
{
using (var w = XmlWriter.Create(Console.Out, new XmlWriterSettings {Indent = true}))
{
EdmxWriter.WriteEdmx(ctx, w);
}
}
}
}
}
```
Comments: verified, closing

Source code checked in, #6e672255a8cae63f2d5d6f8aebb097be074c2410

0
0
Updating Project and License FWLinks for 6.1.2-beta1

Source code checked in, #8355d2c9ed7b9ff5a37fae4f49389dbcff08e9af

0
0
Merge branch 'release-6.1.2-beta1'

Source code checked in, #591c864a5699ea0165e9a5cd0ce8b349a3b1b2eb

0
0
Correcting Project and License FwLinks after merging in changes from release-6.1.2-beta1 branch

Commented Unassigned: Lazy loading [2491]

0
0
Hi everybody,

I have a problem with lazy loading after migrating from EF4 to EF 6.1.1. Everything is working fine but on one class lazy loading won't work. The t4-Template generates this codepiece

public partial class WatchmanServiceAssignment
{
public System.Guid Guid { get; set; }
public System.Guid WatchmanServiceGuid { get; set; }
public System.Guid EmployeeGuid { get; set; }
public System.DateTime Date { get; set; }
public int Begin { get; set; }
public int End { get; set; }
public bool IsBriefing { get; set; }
public Nullable<System.Guid> WageGroupGuid { get; set; }
public Nullable<System.Guid> NontariffBonusGuid { get; set; }
public Nullable<System.Guid> PriceGroupGuid { get; set; }
public int IntermissionMinutes { get; set; }

public virtual Employee Employee { get; set; }
public virtual NontariffBonus NontariffBonus { get; set; }
public virtual PriceGroup PriceGroup { get; set; }
public virtual WageGroup WageGroup { get; set; }
public virtual WatchmanService WatchmanService { get; set; }
}

All other classes generated perform lazy loading as expected. But each query to the above class leads to Null-References in the last 5 Properties. Any ideas? Need more details?

Thanks in advance
Comments: Thanks for your answer. Meanwhile I figured out what happend. During debugging I discovered that objects of type WatchmanServiceAssignment were no proxies whereas other objects in the model were. Digging down the code I discovered a default constructor of WatchmanServiceAssignment that was marked as private. Therefore no proxies were gernerated and lazy loading was switched off.

Commented Issue: getting "entity types cannot share table" for same-named tables in different schemas [1641]

0
0
I pulled CF DbContext classes recently created from EF PowerTools 0.7.0.0 in a VS2012/EF 5.0.0 project into a brand new EF 6.0.0-rc1 project. The app worked fine in EF 5.0.0. Now when I attempt to use the DbContext in EF 6.0.0-rc1 I get the "entity types cannot share table" error (even though the fluent configuration for the classes specify the correct ToTable mappings).

Here is a simplified repro:

```
namespace ConsoleApplication17
{
public class HREmployee
{
public int Id { get; set; }
}

public class Employee
{
public int Id { get; set; }
}

public partial class Bug1641Context : DbContext
{
public DbSet<HREmployee> Employees { get; set; }
public DbSet<Employee> NonHREmployees { get; set; }

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<HREmployee>().ToTable("Employee", "hr");
modelBuilder.Entity<Employee>().ToTable("RegularEmployees");
}
}

class Program
{
static void Main(string[] args)
{
using (var ctx = new Bug1641Context())
{
using (var w = XmlWriter.Create(Console.Out, new XmlWriterSettings {Indent = true}))
{
EdmxWriter.WriteEdmx(ctx, w);
}
}
}
}
}
```
Comments: @JoshClose: this is now in our [nightly builds](https://entityframework.codeplex.com/wikipage?title=Nightly%20Builds) available as a NuGet package on MyGet. We are also planning on shipping a preview of 6.1.2 to NuGet really soon. HTH, Diego

Commented Unassigned: Revisit usage of (localdb)\v11.0 in ProductivityAPI tests [2505]

0
0
See change #0079b18. In it I reverted some changes I'd put in to get several tests in the 2 test classes DatabaseTests.cs and SimpleScenariosForLocalDb.csto make them work on VS14. The problem was that on VS14 the version of localdb that comes with VS is referred to using "(localdb)\MSSQLLocalDB" whereas previously it was "(localdb)\v11.0".

Unfortunately the "fix" actually broke on the CI machine (which has VS2012 installed) as it depended on the MSBuild variables VS11, VS12 etc. Those build variables are not defined on a runtime build - hence the need to revert.

We don't want to produce different versions of the runtime

But those tests will still fail on a VS14 box. So we need to find a way to update the code appropriately.

Note that these changes were only in the test code - so it _may_ be OK to set up to depend on those environment variables for the test build only. But note from avickers: "we do not want people to have to change the current way they build - so it should default to something reasonable if no environment variable is set."

Perhaps set up a new env var e.g. EF6LocalDBName whose value can be v11.0 or MSSQLLocalDB and which defaults to v11.0 if not set? Then we can change the VS14 build to set that env var.

Comments: If we can select v11.0 or MSSQLLocalDB at test runtime, then we could possibly use similar detection logic to what we have in EntityFramework.PowerShell.SqlServerDetector.GetLocalDBVersionInstalled().

Edited Unassigned: After upgrade to 6.1.1 columns are renamed by code first migration [2500]

0
0
After an upgrade from EF 6.1.0 to 6.1.1 my application complained about a changed model and required an explicit migration. However, to my suprise, it wasn't simply a small change in something like a default length or any other 'non fundamental' change. No, it wanted to switch a few columns.
Currently I'm thinking it is only occurring in classes where multiple relations to a single other entity exist (In th example below; both Branch and Customer are an Organization with an exposed FK in Assignment)

One of those would be (cut out some others):
public override void Up()
{
DropIndex("dbo.Assignments", new[] { "CustomerId" });
DropIndex("dbo.Assignments", new[] { "BranchId" });

RenameColumn(table: "dbo.Assignments", name: "CustomerId", newName: "__mig_tmp__0");
RenameColumn(table: "dbo.Assignments", name: "BranchId", newName: "CustomerId");
RenameColumn(table: "dbo.Assignments", name: "__mig_tmp__0", newName: "BranchId");

AlterColumn("dbo.Assignments", "BranchId", c => c.Guid());
AlterColumn("dbo.Assignments", "CustomerId", c => c.Guid(nullable: false));

CreateIndex("dbo.Assignments", "CustomerId");
CreateIndex("dbo.Assignments", "BranchId");
}

The code of Assignment was not changed at all so I'm quite confident that a change in the migration logic is causing this altered interpretation.

All thoughts, work-arounds/solutions/etc., are most welcome.

Commented Unassigned: After upgrade to 6.1.1 columns are renamed by code first migration [2500]

0
0
After an upgrade from EF 6.1.0 to 6.1.1 my application complained about a changed model and required an explicit migration. However, to my suprise, it wasn't simply a small change in something like a default length or any other 'non fundamental' change. No, it wanted to switch a few columns.
Currently I'm thinking it is only occurring in classes where multiple relations to a single other entity exist (In th example below; both Branch and Customer are an Organization with an exposed FK in Assignment)

One of those would be (cut out some others):
public override void Up()
{
DropIndex("dbo.Assignments", new[] { "CustomerId" });
DropIndex("dbo.Assignments", new[] { "BranchId" });

RenameColumn(table: "dbo.Assignments", name: "CustomerId", newName: "__mig_tmp__0");
RenameColumn(table: "dbo.Assignments", name: "BranchId", newName: "CustomerId");
RenameColumn(table: "dbo.Assignments", name: "__mig_tmp__0", newName: "BranchId");

AlterColumn("dbo.Assignments", "BranchId", c => c.Guid());
AlterColumn("dbo.Assignments", "CustomerId", c => c.Guid(nullable: false));

CreateIndex("dbo.Assignments", "CustomerId");
CreateIndex("dbo.Assignments", "BranchId");
}

The code of Assignment was not changed at all so I'm quite confident that a change in the migration logic is causing this altered interpretation.

All thoughts, work-arounds/solutions/etc., are most welcome.
Comments: Assigning to Emil for investigation.

Commented Unassigned: Cascade delete [2496]

0
0
Hi

As I understand, EF currently only provides support for cascade deleting in-memory objects, and leaves it up to the developer to implement cascade delete on the database layer.

I am aware of the fact that this can be circumvented through the use of a "shared key", however, I would prefer (and I suspect ther majority of the developer community would concur) to maintain strong OO principles (and leave hacks like these out of the equation). After all, ORM starts to lose values when database concerns seeps into your application / class design.

My suggestion is that EF migrations will generate sql code / stored procedure that will add (Up) / remove (Down) cascade deletion triggers, based on the following input parameters:
- Refactor the WillCascadeOnDelete(bool) function to rather take "Off", "CascadeDeleteInMemory" or "CascadeDeleteBySQL" as input in stead of bool (Recommended)
- Alternatively, specify the cascade delete method to use when generating migration scripts as a flag when using the add-migration command


More information on the problem can be found at the following links:
* http://stackoverflow.com/questions/17487577/entity-framework-ef-code-first-cascade-delete-for-one-to-zero-or-one-relations
* http://stackoverflow.com/questions/21314113/entity-framework-6-code-first-cascade-delete
* http://stackoverflow.com/questions/13400484/entity-framework-code-first-5-cascade-delete-on-many-to-many-tables-error
* http://blogs.msdn.com/b/alexj/archive/2009/08/19/tip-33-how-cascade-delete-really-works-in-ef.aspx
* http://lostechies.com/jimmybogard/2014/05/08/missing-ef-feature-workarounds-cascade-delete-orphans/
Comments: Hi @RoMiller Thanks for the feedback. I was not aware that this occurs at database creation. I do understand your reasoning from an austere and purist point of view. However, surely, from a pragmatic point of view, can you see that this functionality will make the lives of developers easier? Seeing as it is optional, the developer will explicitly have to define this behaviour. At the very least, can you indicate whether we will be able to extend EF migrations on our own to include such functionality, if we wish?

Created Unassigned: EDM fails to recognise our 64 bit EF provider for EF 6 [2506]

0
0
we are developing an EF provider to support one of our databases. We have 32 bit EF provider which uses 32 bit db provider and it works fine. But we have some issues with our 64 bit EF provider which depends on 64 bit dbprovider. If we manually add reference to our EF provider in the application and keep the application process architecture as 64 bit, it works fine. But moment we use EDM to use Database First approach, EDM wizard fails with a message implying it was not able to find the compatible dbprovider. From our debugging, it appears the EDM is trying to create a AppDomain(as a 32 bit) and try to load the project exe(which is 64 bit) and in that process it fails complaining about a mismatch in process architecture. The Fusion Log is not showing any reference to our providers(EF or DB).

Any known issues or any clue as to what may be wrong here?

Any help or suggestion much appreciated.


Created Unassigned: Remove the EF5 sample provider from CodePlex [2507]

0
0
The sample provider on CodePlex is for EF5 and is essentially the same as the one in the Code Gallery. It is confusing having this on CodePlex with the EF6 source. For creating EF6 providers the SQL Server and/or SQL Compact source trees are a much better starting point. We should delete the sample provider from CodePlex, perhaps after moving the updated "publish.cmd" file to the Code Gallery.

New Comment on "Handling of Transaction Commit Failures "

0
0
Hi, I have an issue that I'm running into regarding the commitFailureHandler.ClearTransactionHistory() method. When I run this for the very first time, I get an exception that states 'dbo.EFTransactionHistory' is invalid. InnerException: System.Data.SqlClient.SqlException HResult=-2146232060 Message=Invalid object name 'dbo.EFTransactionHistory'. Source=.Net SqlClient Data Provider ErrorCode=-2146232060 Class=16 LineNumber=1 Number=208 Procedure="" Server=******** State=1 I checked in the database & of course that table does not exist. Of course we should be executing this method every time the application starts up. In this case, it is a WCF service & I made a custom Service Initializer so whenever the mex is initiated or the very first service call comes in it initializes some resources that the service will need. Here is what I have in my web.config for my service: <entityFramework codeConfigurationType="WSI.Common.DataAccess.Configuration.EntityFramework.TransactionDbConfiguration, WSI.Common.DataAccess"> Here I extend the DbConfiguration class with the following code: public class TransactionDbConfiguration : DbConfiguration { public TransactionDbConfiguration() { SetTransactionHandler(SqlProviderServices.ProviderInvariantName, () => new CommitFailureHandler(c => new DbTransactionContext(c))); SetExecutionStrategy(SqlProviderServices.ProviderInvariantName, () => new SqlAzureExecutionStrategy()); } } Next is my code that I extend the TransactionContext class with: public class DbTransactionContext : TransactionContext { public DbTransactionContext(DbConnection dbConnection) : base(dbConnection) { } protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Entity<TransactionRow>().ToTable("EFTransactionHistory"); } } Then in my ServiceInitializer class, I call a static method by passing an instance of the DbContext like so: protected static void Initialize(DbContext dbContext) { if (dbContext != null) { using (CommitFailureHandler commitFailureHandler = CommitFailureHandler.FromContext(dbContext)) { if (commitFailureHandler != null) { commitFailureHandler.ClearTransactionHistory(); //commitFailureHandler.PruneTransactionHistory(); } } } } Of course if I remove the commitFailureHandler.ClearTransactionHistory(); & I run the application, once I update any of my entities in the database during the normal course of when the service runs, it will create the dbo.EFTransactionHistory table. Then I stop the service, I include the commitFailureHandler.ClearTransactionHistory(); method it will works. Some how the ClearTransactionHistory should be checking to see if the table exists before attempting to delete the rows from the table or it triggers the OnModelCreating method. I've been working on this for a few days now & I would love to find a way to solve this issue. Thanks

Commented Issue: Designer: Issue replacing $edmxInputFile$ when edmx is a linked file [450]

0
0
http://blogs.msdn.com/b/adonet/archive/2011/09/28/ef-4-2-model-amp-database-first-walkthrough.aspx#10338460

Jorris
08-10-2012 3:38 AM
#

Found a little bug for the .tt Wizard. (Microsoft.Data.Entity.Design.VisualStudio.ModelWizard.AddArtifactGeneratorWizard)

When you add the .emdx file as a link from another project in another solution, the $edmxInputFile$ in the .tt templates gets replaced properly, so with the relative path "..\..\" etc, but when you add the .edmx file as a link from another project in the same solution the $edmxInputFile$ doesn't get a relative path and an exception is thrown.

Not sure if one would even need to do this, but it shouldn't crash at least.

Thx.
Comments: See http://stackoverflow.com/questions/16610602/ef5-starting-a-project/25881318#25881318

Created Unassigned: Remove Entity Association [2508]

0
0
I have two entities, EntityA and EntityB with a 0..1 to many relationship. EntityB is associated with an EntityA entity. I want to remove that association.

I would expect this to work:
var entityB = context.EntityB.First();
entityB.EntityA = null;
context.SaveChanges();

However, if I request entityB.EntityA after SaveChanges it will return the record it was associated with before setting it to null.

However, if I do this:
var entityB = context.EntityB.First();
if (entityB.EntityA != null) {
entityB.EntityA = null;
}
context.SaveChanges();

Then it works.

Included is a test project made in VS2013 with EntityFramework 6.1.1 package and tested against SQL Server 2008 R2. SQL create script is included.

Created Unassigned: Allow setting CommandTimeout in app.config [2509]

0
0
Entity Framework already has app.config sections for the context object. Can we get a feature that allows us to set the CommandTimeout somewhere in there?
Viewing all 10318 articles
Browse latest View live




Latest Images