Edited Issue: ObjectContext.EnsureConnection() could cause a connection leak [1159]

January 16, 2014, 2:18 pm

≫ Next: Edited Task: Use consistent approach to TransactionContext database initialization [1925]

≪ Previous: Edited Issue: Ordering issue for IsUnicode between attributes and properties conventions [1665]

The delegate passed to EnsureContextIsEnlistedInCurrentTransaction increases the connectionRequestCount, but this isn't correct as no additional requests were made and therefore there won't be and additional call to ReleaseConnection in that case resulting in the connection not being closed.

The delegate is only invoked when the ambient transaction changed after the last time EnsureConnection() was called and the connection hasn't been closed yet. This is a pretty rare case.

↧

Edited Task: Use consistent approach to TransactionContext database initialization [1925]

January 16, 2014, 2:21 pm

≫ Next: Edited Issue: Check for Unbounded in EdmModelDiffer.BuildColumnModel [1901]

≪ Previous: Edited Issue: ObjectContext.EnsureConnection() could cause a connection leak [1159]

CommitFailureHandler.BuildDatabaseInitializationScript should use migrations sql generator if available.
TransactionContextInitializer should fallback to legacy script creation if migrations sql generator is not available.

↧

Edited Issue: Check for Unbounded in EdmModelDiffer.BuildColumnModel [1901]

January 16, 2014, 2:22 pm

≫ Next: Edited Issue: Known issues in commit failure handling implementation [1926]

≪ Previous: Edited Task: Use consistent approach to TransactionContext database initialization [1925]

MaxLength, Precision and Scale facets could have an Unbounded value which would result in an InvalidCastException.

↧

Edited Issue: Known issues in commit failure handling implementation [1926]

January 16, 2014, 2:24 pm

≫ Next: Closed Issue: Designer in VS2013: Generate Database from Model Error: Unable to convert runtime connection string to its design-time equivalent [1838]

≪ Previous: Edited Issue: Check for Unbounded in EdmModelDiffer.BuildColumnModel [1901]

Here are some API related comments from the commit failure workaround work:

1. The name TransactionHandler suggests that it can do more than it can actually do. Given that we have IDbTransactionInterceptor, do we need to have the general concept of a TransactionHandler or can we steer the design towards the more constrained idea of a CommitFailuresHandler. We can call the default one "DefaultCommitFailuresHandler" and the one that implements the workaround something else, e.g. "ResilientCommitFailuresHandler", "LoggingCommitFailuresHandler" or "CheckingCommitFailuresHandler" (or some better idea).

2. DbConfiguration.SetTransactionHandler that doesn't take a provider name: In other cases we have called this the "default", e.g. SetDefaultHistoryContext, SetDefaultSpatialServices. We should try to be consistent.

3. SetTransactionHandler overloads that take a provider name: in other cases we have made the provider name the first parameter.

4. SetTransactionContext: Does knowledge about the transaction context really need to leak outside the transaction handler? Could things still work and be reasonably extensible without it being a public type?

5. Consider renaming __Transactions table to __TransactionHistory (which looks nice alongside __MigrationsHistory :)) or __TransactionLog

6. Consider renaming PruneTransactionRows => PruneTransactionHistory[Async] or PruneTransactionLog[Async] in alignment to #5.

7. Provide a way to get the transaction handler from any context (even DbContext), e.g. a static CommitFailuresHandler.FromContext(db)

8. Provide a way to remove all rows in application start, e.g. CommitFailuresHandler.FromContext(db).TruncateTransaction<History|Log>[Async]

9. Merge ExecutionStrategyKey and StoreKey?

↧

Closed Issue: Designer in VS2013: Generate Database from Model Error: Unable to convert runtime connection string to its design-time equivalent [1838]

January 16, 2014, 2:41 pm

≫ Next: Closed Issue: Make it clearer that a required rebuild may be the reason EF Designer can't find an EF6 provider [1942]

≪ Previous: Edited Issue: Known issues in commit failure handling implementation [1926]

This error occurs in the the designer with Visual Studio 2013 when running Generate Database from Model when using a 3rd party provider or even the SQL Server Compact provider in an EDMX based project,.

(The EF6 designer in VS 2012 does works fine when doing this)

The entity connection string in app.config is present and correct.

Also see this on SO : http://stackoverflow.com/questions/19983270/unable-to-convert-runtime-exception-string-to-its-desing-time-equivalent

I have attached a repro project. (Without EF binaries)

The error comes from:
```
TranslateConnectionString(Project project, string invariantName, string connectionString, bool isDesignTime)
```
As per https://entityframework.codeplex.com/discussions/403680 MySQL connector now supports VS2013. We should make sure that either MySQL is not affected by this issue or the fix works for MySQL as well.

There is a related bug which I originally thought was causing the problem but it actually seems to be a separate issue: https://entityframework.codeplex.com/workitem/1869
Comments: Verified as "fixed." The error message looks to properly explain the issue, and is displaying at the correct times.

↧

Closed Issue: Make it clearer that a required rebuild may be the reason EF Designer can't find an EF6 provider [1942]

January 16, 2014, 2:51 pm

≫ Next: Commented Task: Add Viability Checks to Build [1996]

≪ Previous: Closed Issue: Designer in VS2013: Generate Database from Model Error: Unable to convert runtime connection string to its design-time equivalent [1838]

Adding the SQL CE provider to VS2012 and going through the designer wizard results in the following error message at the version selection stage (only occurs if the project hasn't been built since adding the provider):
> Your project references the latest version of Entity Framework; however, an Entity Framework database provider compatible with this version could not be found for your data connection. Exit this wizard, install a compatible provider, and rebuild your project before performing this action.

This issue can be solved by rebuilding the project after adding the provider and before going through the wizard. However, this is not particularly clear from the error message. We should probably do something to emphasize "You may need to rebuild your project" because it's not immediately clear that rebuilding may be all you need to do.
Comments: The new error message looks perfect. Verified as fixed.

↧

Commented Task: Add Viability Checks to Build [1996]

January 16, 2014, 3:03 pm

≫ Next: Created Unassigned: EF6 Upgrade Causes Severe Performance Degradation [2001]

≪ Previous: Closed Issue: Make it clearer that a required rebuild may be the reason EF Designer can't find an EF6 provider [1942]

Add checks that run after the nightly build to do further checks that the output of the build is as expected. E.g.

1. That we have the correct files (both dated and non-dated versions)
2. That the AssemblyVersion, AssemblyFileVersion and AssemblyFileInfoVersion attributes are correct
3. That the assemblies and scripts within the .nupkgs are digitally signed
Comments: Found that the nightly build also needed to download NuGet.exe first. Checked in with #55818c6.

↧

Created Unassigned: EF6 Upgrade Causes Severe Performance Degradation [2001]

January 16, 2014, 3:13 pm

≫ Next: Updated Wiki: Design Meeting Notes – January 16, 2014

≪ Previous: Commented Task: Add Viability Checks to Build [1996]

We are running EF 5.0 currently on .NET 4.5.1 with ASP.NET MVC 5 and ASP.NET Web Api 2.

We have now attempted an update to Entity Framework 6.0.2 twice now.

The first time we did it our site slowed to a crawl, database connections started climbing and we had to roll back the upgrade.

We went back and did some reading and found the transaction behavior around ExecuteSqlCommand had changed so we went through and updated all our usages to specific no transaction essentially reverting to the old behavior.

Redeploy and site slows to a crawl again while connections climb. Roll back release and start over.

Done some searching around on StackOverflow, etc and so far have seen no one reporting similar symptoms. We are stymied as to what might be going on and could use some thoughts from the community on how to start triangulating the issue...

Did something change around connection pooling?

Thanks,

Chris

↧

Updated Wiki: Design Meeting Notes – January 16, 2014

January 16, 2014, 3:43 pm

≫ Next: Updated Wiki: Design Meeting Notes

≪ Previous: Created Unassigned: EF6 Upgrade Causes Severe Performance Degradation [2001]

EF6.1.0 API Review

The purpose of API Review meetings is to go over new API surface one class/member at a time to ensure we have a consistent and high quality API. We look at how classes are structured, which members are public as well as the names of classes, members and parameters.

Comparing 6.0.2 RTM to the 6.1.0 nightly build from Jan-15-2014 we decided on the following changes:

T:System.ComponentModel.DataAnnotations.Schema.CompatibilityResult

Move this type to the same namespace as the annotation/attribute infrastructure

T:System.ComponentModel.DataAnnotations.Schema.IndexAttribute

Remove the ClusteredConfiguration and UniqueConfiguration methods and introduce IsClusteredConfigured and IsUniqueConfigured to identify if the corresponding properties have been set (these will only have a getter).

IsCompatibleWith & MergeWith can be made internal and moved to be helper methods.

T:System.Data.Entity.DbConfiguration

SetAnnotationCodeGenerator should be removed from this class and just be configurable on the Migrations Code Generator. We want it to be settable on the default instance rather than having to derive from the class and override things.

T:System.Data.Entity.Core.Mapping.EndPropertyMapping

AddProperty/RemoveProperty should be renamed to AddPropertyMapping/RemovePropertyMapping – this applies to various other APIs in the System.Data.Entity.Core.Mapping namespace too.

T:System.Data.Entity.Core.Mapping.Map

Rename to MappingBase.

T:System.Data.Entity.Core.Mapping.StructuralTypeMapping

Rename Properties to MappingProperties

N:System.Data.Entity.Infrastructure

Create a System.Data.Entity.Infrastructure.Annotations namespace and move all annotation types into it (including CompatibilityResult that used to be in System.ComponentModel.DataAnnotations.Schema).

T:System.Data.Entity.Infrastructure.IMetadataAnnotationSerializer

Rename SerializeValue/DeserializeValue to Serialize/Deserialize.

T:System.Data.Entity.Infrastructure.IMergeableAnnotation

Rename ‘indexes’ parameter to ‘indexAttributes’ in the following APIs:

public IndexAnnotation(IEnumerable<IndexAttribute> indexes);
public IndexAnnotation(IndexAttribute index);
public virtual IEnumerable<IndexAttribute> Indexes { get; }

T:System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher

Rename ‘dbConnection’ parameters to ‘connection’

T:System.Data.Entity.Migrations.AnnotationPair

Rename to AnnotationValues.

T:System.Data.Entity.Migrations.Design.MigrationCodeGenerator

AnnotationGenerators should be public (per decision to remove DbConfiguration.SetAnnotationCodeGenerator).

RegisterAnnotationGenerators can be removed now that DbConfiguration config point is being removed.

T:System.Data.Entity.Migrations.Model.AlterTableAnnotationsOperation

Remove ‘Annotations’ and make it a more generic AlterTableOperation (to support anything we add in the future).

T:System.Data.Entity.ModelConfiguration.EntityTypeConfiguration`1

Rename HasAnnotation to HasTableAnnotation (plus other relevant places in the code base).

T:System.Data.Entity.ModelConfiguration.Configuration.BinaryPropertyConfiguration

Rename HasAnnotation to HasColumnAnnotation (plus other relevant places in the code base).

↧

Updated Wiki: Design Meeting Notes

January 16, 2014, 3:46 pm

≫ Next: Updated Wiki: Design Meeting Notes – January 16, 2014

≪ Previous: Updated Wiki: Design Meeting Notes – January 16, 2014

Entity Framework Design Meeting Notes

The Entity Framework team has a weekly design meeting in which we discuss/recap design and other issues with the codebase. These are the notes from those meetings. The intention is to provide a history of what decisions have been made and why. No attempt is made to go back and update notes from older meetings if we later change a decision and decide to do something different.

January 16, 2014

EF 6.1.0 API Review

January 9, 2014

Scaffolded empty DbContext for Code First

December 5, 2013

New Database.Log content
Designer “White Tests”
Index attribute

October 17, 2013

Code First in the new EDM wizard
Open-sourcing the EF Tools
Adding new interception interfaces
Plan for transaction commit failure workaround

October 3, 2013

Entity Framework 6.0.1 performance status

July 26, 2013

API Review: Interception
API Review: Code First Stored Procedure Mapping

July 18, 2013

General API review and cleanup

July 10, 2013

API Review: Code Based Config & Dependency Resolution

July 5, 2013

Handling connection failures on transaction commit

June 6, 2013

HasPrecision in lightweight conventions
Make command tree interception internal for EF6?

May 16, 2013

Time format in DbCommandLogger
Potential breaking change to IDbSet
Conversion to lightweight conventions

May 9, 2013

Interception building blocks
DbContext.Database.Log

April 11, 2013

Default providers
- The default connection factory
- Default provider configuration
- Additional config file elements
- DbProviderServices methods
Model-based conventions exploratory testing

April 4, 2013

Revisit: Using ExecuteSqlCommand without a transaction
Revisit: Extension method class naming
New transient error codes

April 2, 2013

API Review: Multiple Contexts per Database
API Review: Configurable Migrations History Table

March 28, 2013

Rename of DbExtensions to IQueryableExtensions
Pattern for customizing migrations history table
Turning off automatic transaction creation
Buffering in EntityClient

March 21, 2013

Missing property handling in lightweight conventions
Code First stored procedure mapping

March 19, 2013

Connection Resiliency Review

March 18, 2013

Async Query & Save API Review

March 14, 2013

File/code-based configuration precedence

March 13, 2013

Custom Code First Conventions

March 7, 2013

Custom migration operations usability
WrapService naming
Database initializers and shared databases

February 28, 2013

Models with nested types in Code First
Configuration of connection resiliency execution strategy
Behavior of disposed DbContextTransaction

February 20, 2013

Mapping to fields
Removal of unused resources

February 14, 2013

Branching for EF releases
Pull request: extending Migrations
Code First: modification function mapping API (mapping to stored procs)

February 7, 2013

DbContext and transactions (continued)
Pull request: extending Migrations
Issues with SQL Server spatial types

January 31, 2013

DbContext and transactions
Code First: modification function mapping (mapping to stored procs)

January 24, 2013

Buffering data reader perf
Provider-agnostic testing
Porting old SQL tests

January 17, 2013

Metadata API surface
Pluralization service exploratory testing feedback
Metadata unification
Porting existing SQL tests
How should pluralizers be made available?

January 10, 2013

Clustered/non-clustered unique identifier primary keys and SQL Azure

December 13, 2012

Lightweight conventions
Clustered/non-clustered unique identifier primary keys
Potential contribution for pluralization service

December 6, 2012

Additional ObjectContext and EntityConnection constructors
Default schema changes during initialization
Making EF queries buffer by default
SQL Azure connection resiliency
WET, DAMP, or DRY tests

November 29, 2012

Handling pull requests
Making READ_COMMITTED_SNAPSHOT the default
Database First WinForms data binding

November 20, 2012

Automatic EntityTypeConfiguration discovery

November 15, 2012

Lightweight conventions
View generation API
Removal of Code Contracts

November 8, 2012

Lightweight conventions
Connection resiliency to transient failures

October 25, 2012

Change default mapping for DateTime
Lightweight conventions
DbConfiguration exploratory testing
Code Contracts discussion

October 11, 2012

Lightweight conventions

October 4, 2012

Global spatial provider
Set-based configuration

September 27, 2012

Dependency resolver scoping
Sugar methods for services
Simplified API for common conventions

September 20, 2012

By-convention parameter binding SqlQuery overload
SqlCE relative path connection string UX issues with Migrations
Pluggable Conventions
Polish the conventions API
Breaking change

August 23, 2012

Make ObjectContext implement IObjectContextAdapter
Migrations multi-tenancy
Designer versioning
Async protection

August 9, 2012

Getting schema Information from providers
Using IDbDependencyResolver with existing IoC containers

August 2, 2012

CUD Batching
Bulk operations

July 26, 2012

Async
One-pagers
Initializer proposal

July 12, 2012

Model key caching
Migrations history table schema changes
Async immediate LINQ operators

July 5, 2012

Refactoring and unit tests

June 28, 2012

Code contracts

June 21, 2012

Code-based configuration

June 14, 2012

Making database connections in the test suite more configurable

June 7, 2012

Naming convention for static readonly and const fields
How will we handle breaking changes in EF6?
High-level ideas for using dependency injection with EF and specifics for the provider

May 31, 2012

Making EF code more testable
Code duplication in Async
Supporting MVC scaffolding

↧

Updated Wiki: Design Meeting Notes – January 16, 2014

January 16, 2014, 3:46 pm

≫ Next: Updated Wiki: Design Meeting Notes – January 16, 2014

≪ Previous: Updated Wiki: Design Meeting Notes

EF6.1.0 API Review

Comparing 6.0.2 RTM to the 6.1.0 nightly build from Jan-15-2014 we decided on the following changes:

T:System.ComponentModel.DataAnnotations.Schema.CompatibilityResult

Move this type to the same namespace as the annotation/attribute infrastructure

T:System.ComponentModel.DataAnnotations.Schema.IndexAttribute

IsCompatibleWith & MergeWith can be made internal and moved to be helper methods.

T:System.Data.Entity.DbConfiguration

T:System.Data.Entity.Core.Mapping.EndPropertyMapping

AddProperty/RemoveProperty should be renamed to AddPropertyMapping/RemovePropertyMapping – this applies to various other APIs in the System.Data.Entity.Core.Mapping namespace too.

T:System.Data.Entity.Core.Mapping.Map

Rename to MappingBase.

T:System.Data.Entity.Core.Mapping.StructuralTypeMapping

Rename Properties to MappingProperties

N:System.Data.Entity.Infrastructure

Create a System.Data.Entity.Infrastructure.Annotations namespace and move all annotation types into it (including CompatibilityResult that used to be in System.ComponentModel.DataAnnotations.Schema).

T:System.Data.Entity.Infrastructure.IMetadataAnnotationSerializer

Rename SerializeValue/DeserializeValue to Serialize/Deserialize.

T:System.Data.Entity.Infrastructure.IMergeableAnnotation

Rename ‘indexes’ parameter to ‘indexAttributes’ in the following APIs:

public IndexAnnotation(IEnumerable<IndexAttribute> indexes);
public IndexAnnotation(IndexAttribute index);
public virtual IEnumerable<IndexAttribute> Indexes { get; }

T:System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher

Rename ‘dbConnection’ parameters to ‘connection’

T:System.Data.Entity.Migrations.AnnotationPair

Rename to AnnotationValues.

T:System.Data.Entity.Migrations.Design.MigrationCodeGenerator

AnnotationGenerators should be public (per decision to remove DbConfiguration.SetAnnotationCodeGenerator).

RegisterAnnotationGenerators can be removed now that DbConfiguration config point is being removed.

T:System.Data.Entity.Migrations.Model.AlterTableAnnotationsOperation

Remove ‘Annotations’ and make it a more generic AlterTableOperation (to support anything we add in the future).

T:System.Data.Entity.ModelConfiguration.EntityTypeConfiguration`1

Rename HasAnnotation to HasTableAnnotation (plus other relevant places in the code base).

T:System.Data.Entity.ModelConfiguration.Configuration.BinaryPropertyConfiguration

Rename HasAnnotation to HasColumnAnnotation (plus other relevant places in the code base).

↧

Updated Wiki: Design Meeting Notes – January 16, 2014

January 16, 2014, 3:47 pm

≫ Next: Updated Wiki: Design Meeting Notes – January 16, 2014

≪ Previous: Updated Wiki: Design Meeting Notes – January 16, 2014

EF 6.1.0 API Review

Comparing 6.0.2 RTM to the 6.1.0 nightly build from Jan-15-2014 we decided on the following changes:

T:System.ComponentModel.DataAnnotations.Schema.CompatibilityResult

Move this type to the same namespace as the annotation/attribute infrastructure

T:System.ComponentModel.DataAnnotations.Schema.IndexAttribute

IsCompatibleWith & MergeWith can be made internal and moved to be helper methods.

T:System.Data.Entity.DbConfiguration

T:System.Data.Entity.Core.Mapping.EndPropertyMapping

AddProperty/RemoveProperty should be renamed to AddPropertyMapping/RemovePropertyMapping – this applies to various other APIs in the System.Data.Entity.Core.Mapping namespace too.

T:System.Data.Entity.Core.Mapping.Map

Rename to MappingBase.

T:System.Data.Entity.Core.Mapping.StructuralTypeMapping

Rename Properties to MappingProperties

N:System.Data.Entity.Infrastructure

Create a System.Data.Entity.Infrastructure.Annotations namespace and move all annotation types into it (including CompatibilityResult that used to be in System.ComponentModel.DataAnnotations.Schema).

T:System.Data.Entity.Infrastructure.IMetadataAnnotationSerializer

Rename SerializeValue/DeserializeValue to Serialize/Deserialize.

T:System.Data.Entity.Infrastructure.IMergeableAnnotation

Rename ‘indexes’ parameter to ‘indexAttributes’ in the following APIs:

public IndexAnnotation(IEnumerable<IndexAttribute> indexes);
public IndexAnnotation(IndexAttribute index);
public virtual IEnumerable<IndexAttribute> Indexes { get; }

T:System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher

Rename ‘dbConnection’ parameters to ‘connection’

T:System.Data.Entity.Migrations.AnnotationPair

Rename to AnnotationValues.

T:System.Data.Entity.Migrations.Design.MigrationCodeGenerator

AnnotationGenerators should be public (per decision to remove DbConfiguration.SetAnnotationCodeGenerator).

RegisterAnnotationGenerators can be removed now that DbConfiguration config point is being removed.

T:System.Data.Entity.Migrations.Model.AlterTableAnnotationsOperation

Remove ‘Annotations’ and make it a more generic AlterTableOperation (to support anything we add in the future).

T:System.Data.Entity.ModelConfiguration.EntityTypeConfiguration`1

Rename HasAnnotation to HasTableAnnotation (plus other relevant places in the code base).

T:System.Data.Entity.ModelConfiguration.Configuration.BinaryPropertyConfiguration

Rename HasAnnotation to HasColumnAnnotation (plus other relevant places in the code base).

↧

Updated Wiki: Design Meeting Notes – January 16, 2014

January 16, 2014, 3:47 pm

≫ Next: Commented Task: API review for API surface changes in 6.1.0 [1974]

≪ Previous: Updated Wiki: Design Meeting Notes – January 16, 2014

EF 6.1.0 API Review

Comparing 6.0.2 RTM to the 6.1.0 nightly build from Jan-15-2014 we decided on the following changes:

T:System.ComponentModel.DataAnnotations.Schema.CompatibilityResult

Move this type to the same namespace as the annotation/attribute infrastructure

T:System.ComponentModel.DataAnnotations.Schema.IndexAttribute

IsCompatibleWith & MergeWith can be made internal and moved to be helper methods.

T:System.Data.Entity.DbConfiguration

T:System.Data.Entity.Core.Mapping.EndPropertyMapping

AddProperty/RemoveProperty should be renamed to AddPropertyMapping/RemovePropertyMapping – this applies to various other APIs in the System.Data.Entity.Core.Mapping namespace too.

T:System.Data.Entity.Core.Mapping.Map

Rename to MappingBase.

T:System.Data.Entity.Core.Mapping.StructuralTypeMapping

Rename Properties to MappingProperties

N:System.Data.Entity.Infrastructure

Create a System.Data.Entity.Infrastructure.Annotations namespace and move all annotation types into it (including CompatibilityResult that used to be in System.ComponentModel.DataAnnotations.Schema).

T:System.Data.Entity.Infrastructure.IMetadataAnnotationSerializer

Rename SerializeValue/DeserializeValue to Serialize/Deserialize.

T:System.Data.Entity.Infrastructure.IMergeableAnnotation

Rename ‘indexes’ parameter to ‘indexAttributes’ in the following APIs:

public IndexAnnotation(IEnumerable<IndexAttribute> indexes);
public IndexAnnotation(IndexAttribute index);
public virtual IEnumerable<IndexAttribute> Indexes { get; }

T:System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher

Rename ‘dbConnection’ parameters to ‘connection’

T:System.Data.Entity.Migrations.AnnotationPair

Rename to AnnotationValues.

T:System.Data.Entity.Migrations.Design.MigrationCodeGenerator

AnnotationGenerators should be public (per decision to remove DbConfiguration.SetAnnotationCodeGenerator).

RegisterAnnotationGenerators can be removed now that DbConfiguration config point is being removed.

T:System.Data.Entity.Migrations.Model.AlterTableAnnotationsOperation

Remove ‘Annotations’ and make it a more generic AlterTableOperation (to support anything we add in the future).

T:System.Data.Entity.ModelConfiguration.EntityTypeConfiguration`1

Rename HasAnnotation to HasTableAnnotation (plus other relevant places in the code base).

T:System.Data.Entity.ModelConfiguration.Configuration.BinaryPropertyConfiguration

Rename HasAnnotation to HasColumnAnnotation (plus other relevant places in the code base).

↧

Commented Task: API review for API surface changes in 6.1.0 [1974]

January 16, 2014, 3:48 pm

≫ Next: Source code checked in, #095c08bd5d13ff4a18317b8c9def885dfddaee4a

≪ Previous: Updated Wiki: Design Meeting Notes – January 16, 2014

We should review all public surface changes in 6.1.0 using the API review tool.

Note: I created this new API review work item and renamed #[1926](https://entityframework.codeplex.com/workitem/1926) since most of the later is mostly about know issues in commit failure handling that should be addressed by Andriy before we actually do an API review for 6.1.0.
Comments: API Review Notes are here - https://entityframework.codeplex.com/wikipage?title=Design%20Meeting%20Notes%20%e2%80%93%20January%2016%2c%202014 As part of verifying this issue please double check that all recorded decisions were implemented in the code base.

↧

Source code checked in, #095c08bd5d13ff4a18317b8c9def885dfddaee4a

January 16, 2014, 3:57 pm

≫ Next: Edited Issue: Enum columns bails out with many Includes [FixedIn6.1.0-alpha1] [AffectedLastRTM] [1686]

≪ Previous: Commented Task: API review for API surface changes in 6.1.0 [1974]

Updated EFTools after renaming a few public methods in runtime.

↧

Edited Issue: Enum columns bails out with many Includes [FixedIn6.1.0-alpha1] [AffectedLastRTM] [1686]

January 16, 2014, 4:36 pm

≫ Next: Closed Issue: Enum columns bails out with many Includes [FixedIn6.1.0-alpha1] [AffectedLastRTM] [1686]

≪ Previous: Source code checked in, #095c08bd5d13ff4a18317b8c9def885dfddaee4a

#Summary
Sometimes with complicated table relations with enums as keys EntityFramework fails to load entities correctly.
It seems that lots of includes, like this
``` C#
var res = context.Orders
.Include(o => o.Prop1.PropertyState)
.Include(o => o.Prop2)
.Include(o => o.Prop3)
.ToList();
```
where each of the include contains a member of the enum type triggers the behavior.
See attached project for a complete minimalistic (hey, only 5 tables) example.

The above code snippet throws the following exception

```
System.InvalidOperationException was unhandled
HResult=-2146233079
Message=The type of the key field 'PropertyStateId' is expected to be 'EfEnumBug.PropertyState', but the value provided is actually of type 'System.Int32'.
Source=EntityFramework
StackTrace:
at System.Data.Entity.Core.EntityKey.ValidateTypeOfKeyValue(MetadataWorkspace workspace, EdmMember keyMember, Object keyValue, Boolean isArgumentException, String argumentName)
at System.Data.Entity.Core.EntityKey.ValidateEntityKey(MetadataWorkspace workspace, EntitySet entitySet, Boolean isArgumentException, String argumentName)
at System.Data.Entity.Core.EntityKey.ValidateEntityKey(MetadataWorkspace workspace, EntitySet entitySet)
at System.Data.Entity.Core.Objects.ObjectStateManager.CheckKeyMatchesEntity(IEntityWrapper wrappedEntity, EntityKey entityKey, EntitySet entitySetForType, Boolean forAttach)
at System.Data.Entity.Core.Objects.ObjectStateManager.AddEntry(IEntityWrapper wrappedObject, EntityKey passedKey, EntitySet entitySet, String argumentName, Boolean isAdded)
at System.Data.Entity.Core.Common.Internal.Materialization.Shaper.HandleEntityAppendOnly[TEntity](Func`2 constructEntityDelegate, EntityKey entityKey, EntitySet entitySet)
at lambda_method(Closure , Shaper )
at System.Data.Entity.Core.Common.Internal.Materialization.Coordinator`1.ReadNextElement(Shaper shaper)
at System.Data.Entity.Core.Common.Internal.Materialization.Shaper`1.RowNestedResultEnumerator.MaterializeRow()
at System.Data.Entity.Core.Common.Internal.Materialization.Shaper`1.RowNestedResultEnumerator.MoveNext()
at System.Data.Entity.Core.Common.Internal.Materialization.Shaper`1.ObjectQueryNestedEnumerator.TryReadToNextElement()
at System.Data.Entity.Core.Common.Internal.Materialization.Shaper`1.ObjectQueryNestedEnumerator.MoveNext()
at System.Data.Entity.Internal.LazyEnumerator`1.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at EfEnumBug.Program.Main(String[] args) in c:\Users\albsun\Desktop\EfEnumBug\EfEnumBug\EfEnumBug\Program.cs:line 37
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

```
I expect it to return a list of orders with all properties set.

I have tried both EntityFramework 5.0.0 and EntityFramework 6.0.0-rc1 with the same result.

#Some observations
* Remove any of the .Include lines above and no exception is thrown
* Change Order.Prop1 from OrderProp1 to ICollection<OrderProp1> and no exception is thrown
* Change Order.Prop2 from ICollection<OrderProp2> to ICollection<OrderProp2> and no exception is thrown.

↧