Rated 3 Stars (out of 5) - 正在学习这东西，下载下来好好学习一下
Reviewed: EF 5.0.0 (九月 26, 2013)
↧
↧
Commented Issue: UpForGrabs: SqlCePropertyMaxLengthConvention should be updated to reflect changes in the standard PropertyMaxLengthConvention [1322]
the PropertyMaxLengthConvention was updated in a recent change to improve extensibility, but the SqlCe version of that convention was not similarly updated. The Sql Ce convention should be updated to use a constant that is set from the constructor in a similar manner to the PropertyMaxLengthConvention
Comments: Erik, We would be happy to process your pull request if you think this is worth doing.
Comments: Erik, We would be happy to process your pull request if you think this is worth doing.
↧
Created Unassigned: Multiple contexts, migrations and shared default schema [1685]
I have a multiple-contexts scenario that I assumed was a common usecase: two contexts that is sharing a default namespace via the modelBuilder.HasDefaultSchema. Every table in my contexts have overridden their schemas with per-context specific schemas, thus no tables are conflicting. The only thing they will share is the CommonSchema.__MigrationHistory table.
Now, scaffolding new migrations for both contexts work fine.
The first time I update the database with the first context, everything is created as expected, including the CommonSchema.__MigrationHistory table.
Next, when I try to update the database with the second context, the update operation fails with error:
SqlException (0x80131904): There is already an object named '__MigrationHistory' in the database.
Clearly, it doesn't "see" that the table is already there. My expectation was that this should just work fine, migration history for the two contexts should live happily together, separated by their ContextKey.
Am I missing something here or is this a bug?
Now, scaffolding new migrations for both contexts work fine.
The first time I update the database with the first context, everything is created as expected, including the CommonSchema.__MigrationHistory table.
Next, when I try to update the database with the second context, the update operation fails with error:
SqlException (0x80131904): There is already an object named '__MigrationHistory' in the database.
Clearly, it doesn't "see" that the table is already there. My expectation was that this should just work fine, migration history for the two contexts should live happily together, separated by their ContextKey.
Am I missing something here or is this a bug?
↧
Edited Unassigned: Multiple contexts, migrations and shared default schema [1685]
I have a multiple-contexts scenario that I assumed was a common usecase: two contexts that is sharing a default namespace via the modelBuilder.HasDefaultSchema. Every table in my contexts have overridden their schemas with per-context specific schemas, thus no tables are conflicting. The only thing they will share is the CommonSchema.__MigrationHistory table.
Now, scaffolding new migrations for both contexts work fine.
The first time I update the database with the first context, everything is created as expected, including the CommonSchema.__MigrationHistory table.
Next, when I try to update the database with the second context, the update operation fails with error:
SqlException (0x80131904): There is already an object named '__MigrationHistory' in the database.
Clearly, it doesn't "see" that the table is already there. My expectation was that this should just work fine, migration history for the two contexts should live happily together, separated by their ContextKey.
__Am I missing something here or is this a bug?__
Update: trying out this scenario without using default schemas, thus migrations table ends up in the dbo namespace: __totally works__. Which strengthen my feeling that there is a bug with shared migration history and custom default schemas.
Now, scaffolding new migrations for both contexts work fine.
The first time I update the database with the first context, everything is created as expected, including the CommonSchema.__MigrationHistory table.
Next, when I try to update the database with the second context, the update operation fails with error:
SqlException (0x80131904): There is already an object named '__MigrationHistory' in the database.
Clearly, it doesn't "see" that the table is already there. My expectation was that this should just work fine, migration history for the two contexts should live happily together, separated by their ContextKey.
__Am I missing something here or is this a bug?__
Update: trying out this scenario without using default schemas, thus migrations table ends up in the dbo namespace: __totally works__. Which strengthen my feeling that there is a bug with shared migration history and custom default schemas.
↧
Edited Unassigned: Multiple contexts, migrations and shared default schema [1685]
I have a multiple-contexts scenario that I assumed was a common usecase: two contexts that is sharing a default namespace via the modelBuilder.HasDefaultSchema. Every table in my contexts have overridden their schemas with per-context specific schemas, thus no tables are conflicting. The only thing they will share is the CommonSchema.__MigrationHistory table.
Now, scaffolding new migrations for both contexts work fine.
The first time I update the database with the first context, everything is created as expected, including the CommonSchema.__MigrationHistory table.
Next, when I try to update the database with the second context, the update operation fails with error:
SqlException (0x80131904): There is already an object named '__MigrationHistory' in the database.
Clearly, it doesn't "see" that the table is already there. My expectation was that this should just work fine, migration history for the two contexts should live happily together, separated by their ContextKey.
__Am I missing something here or is this a bug?__
__Update:__ trying out this scenario without using default schemas, thus migrations table ends up in the dbo namespace: __totally works__. Which strengthen my feeling that there is a bug with shared migration history and custom default schemas.
Now, scaffolding new migrations for both contexts work fine.
The first time I update the database with the first context, everything is created as expected, including the CommonSchema.__MigrationHistory table.
Next, when I try to update the database with the second context, the update operation fails with error:
SqlException (0x80131904): There is already an object named '__MigrationHistory' in the database.
Clearly, it doesn't "see" that the table is already there. My expectation was that this should just work fine, migration history for the two contexts should live happily together, separated by their ContextKey.
__Am I missing something here or is this a bug?__
__Update:__ trying out this scenario without using default schemas, thus migrations table ends up in the dbo namespace: __totally works__. Which strengthen my feeling that there is a bug with shared migration history and custom default schemas.
↧
↧
Commented Issue: UpForGrabs: SqlCePropertyMaxLengthConvention should be updated to reflect changes in the standard PropertyMaxLengthConvention [1322]
the PropertyMaxLengthConvention was updated in a recent change to improve extensibility, but the SqlCe version of that convention was not similarly updated. The Sql Ce convention should be updated to use a constant that is set from the constructor in a similar manner to the PropertyMaxLengthConvention
Comments: Relates to https://entityframework.codeplex.com/workitem/731
Comments: Relates to https://entityframework.codeplex.com/workitem/731
↧
Created Unassigned: Enum columns bails out with many Includes [1686]
#Summary
Sometimes with complicated table relations with enums as keys EntityFramework fails to load entities correctly.
It seems that lots of includes, like this
```
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.
Sometimes with complicated table relations with enums as keys EntityFramework fails to load entities correctly.
It seems that lots of includes, like this
```
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.
↧
Commented Issue: UpForGrabs: SqlCePropertyMaxLengthConvention should be updated to reflect changes in the standard PropertyMaxLengthConvention [1322]
the PropertyMaxLengthConvention was updated in a recent change to improve extensibility, but the SqlCe version of that convention was not similarly updated. The Sql Ce convention should be updated to use a constant that is set from the constructor in a similar manner to the PropertyMaxLengthConvention
Comments: @ErikEJ We would appreciate that and would likely accept this as a pull request if you wanted to do it.
Comments: @ErikEJ We would appreciate that and would likely accept this as a pull request if you wanted to do it.
↧
Commented Issue: UpForGrabs: SqlCePropertyMaxLengthConvention should be updated to reflect changes in the standard PropertyMaxLengthConvention [1322]
the PropertyMaxLengthConvention was updated in a recent change to improve extensibility, but the SqlCe version of that convention was not similarly updated. The Sql Ce convention should be updated to use a constant that is set from the constructor in a similar manner to the PropertyMaxLengthConvention
Comments: Done, but having many issues running build.cmd (FunctionalTests) without errors - should I log an issue?
Comments: Done, but having many issues running build.cmd (FunctionalTests) without errors - should I log an issue?
↧
↧
Commented Issue: UpForGrabs: SqlCePropertyMaxLengthConvention should be updated to reflect changes in the standard PropertyMaxLengthConvention [1322]
the PropertyMaxLengthConvention was updated in a recent change to improve extensibility, but the SqlCe version of that convention was not similarly updated. The Sql Ce convention should be updated to use a constant that is set from the constructor in a similar manner to the PropertyMaxLengthConvention
Comments: Or is it a case of "not woking on my PC" ?
Comments: Or is it a case of "not woking on my PC" ?
↧
Source code checked in, #de0054f9666d7dae965b17b9d318197965d897d6
Fixed two issues with "nvarchar" columns and MaxLength attribute:
- The unbounded MaxLength value wasn't handled correctly when the facets are copied.
- The default facet values weren't obtained from the metadata when migrations are generated.
Work items: 1784, 1771
↧
Commented Unassigned: .RemoveRange does not honour cascade delete [1796]
I have found a bug in removerange and cascade delete in EF 6.0.1.
If I retrieved a list of customers and wanted to remove them and their orders, which are set to cascade delete in both the SQL database and the Model, .RemoveRange does not work on save.
Sample code below:
Dim db as New dbEntities
Dim Customers = db.Customers.Where(function (t) t.LastName="Bloggs").ToList
'This does not work
db.Customers.RemoveRange(Customers)
'This Works
For Each Customer in Customers
db.Customers.Remove(Customer)
Next
Comments: I was able to repro this. If a related Order is also loaded, the following exception is thrown from SaveChanges. System.InvalidOperationException: The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted. at System.Data.Entity.Core.Objects.ObjectContext.PrepareToSaveChanges(SaveOptions options) at System.Data.Entity.Core.Objects.ObjectContext.SaveChanges(SaveOptions options) at System.Data.Entity.Internal.InternalContext.SaveChanges() at System.Data.Entity.Internal.LazyInternalContext.SaveChanges() at System.Data.Entity.DbContext.SaveChanges()
If I retrieved a list of customers and wanted to remove them and their orders, which are set to cascade delete in both the SQL database and the Model, .RemoveRange does not work on save.
Sample code below:
Dim db as New dbEntities
Dim Customers = db.Customers.Where(function (t) t.LastName="Bloggs").ToList
'This does not work
db.Customers.RemoveRange(Customers)
'This Works
For Each Customer in Customers
db.Customers.Remove(Customer)
Next
Comments: I was able to repro this. If a related Order is also loaded, the following exception is thrown from SaveChanges. System.InvalidOperationException: The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted. at System.Data.Entity.Core.Objects.ObjectContext.PrepareToSaveChanges(SaveOptions options) at System.Data.Entity.Core.Objects.ObjectContext.SaveChanges(SaveOptions options) at System.Data.Entity.Internal.InternalContext.SaveChanges() at System.Data.Entity.Internal.LazyInternalContext.SaveChanges() at System.Data.Entity.DbContext.SaveChanges()
↧
Edited Issue: .RemoveRange does not honour cascade delete [1796]
I have found a bug in removerange and cascade delete in EF 6.0.1.
If I retrieved a list of customers and wanted to remove them and their orders, which are set to cascade delete in both the SQL database and the Model, .RemoveRange does not work on save.
Sample code below:
Dim db as New dbEntities
Dim Customers = db.Customers.Where(function (t) t.LastName="Bloggs").ToList
'This does not work
db.Customers.RemoveRange(Customers)
'This Works
For Each Customer in Customers
db.Customers.Remove(Customer)
Next
If I retrieved a list of customers and wanted to remove them and their orders, which are set to cascade delete in both the SQL database and the Model, .RemoveRange does not work on save.
Sample code below:
Dim db as New dbEntities
Dim Customers = db.Customers.Where(function (t) t.LastName="Bloggs").ToList
'This does not work
db.Customers.RemoveRange(Customers)
'This Works
For Each Customer in Customers
db.Customers.Remove(Customer)
Next
↧
↧
Edited Issue: Code First: setting max length and type to "nvarchar" at same time has unexpected results [1784]
This issue resulted from investigation of https://entityframework.codeplex.com/workitem/1771. The issues are probably related.
This is about the interaction between partially specified column types and max length settings for string properties. By partially specified column types I mean using just “nvarchar” rather than “nvarchar(x)” where x is max, 4000, etc.
There are regressions from EF5 here.
The interesting lines are bolded below. (Also see triage decisions in the comment below)
__EF5/SQL Server:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct
Column type set to “nvarchar(max)” and no max length
* Same as above
Column type set to “nvarchar(1234)” and any max length
* __Throws: “The Type nvarchar(1234) is not qualified with a namespace or alias.”__
* Interesting that nvarchar(max) is allowed but nvarchar(1234) is not
Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" Nullable="true"
- Correct
* Database
- nvarchar(128)
- __Could be considered correct if 128 is considered the default value in this case__
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- __Correct, but interestingly different__
* Database
- nvarchar(1234)
- Correct
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __Throws from differ after model creation: “Unhandled Exception: System.FormatException: Input string was not in a correct format.”__
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different
* Database
- Throws
__EF6/SQL Server:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct
Column type set to “nvarchar(max)” and no max length
* Same as above
Column type set to “nvarchar(1234)” and any max length
* __Throws: “System.InvalidOperationException: Sequence contains no matching element”__
* The exception is not good, but is thrown for the same reason as the EF5 exception
* __Will file a new bug for this; do not fix as part of this bug.__
Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- __Could be considered correct, but different from EF5 behavior__
* Database
- nvarchar(4000)
- __Again, could be considered correct, but different from EF5__
- __As described in the comments section, this seems like the correct behavior and we will keep it going forward.__
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
* Database
- nvarchar(1234)
- Correct
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __No exception in EF6__
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different as in EF5
* Database
- nvarchar(128)
- __Wrong, but matches EF5 case with nvarchar and no max length__
- __See comments below: this should be fixed to generate nvarchar(4000)__
__EF6/SQL Compact:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="4000" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- As expected for SQL CE due to max length convention
Column type set to “nvarchar” and no max length
* Same as above
Anything that sets column type set to “nvarchar(max)” or “nvarchar(1234)”
* Throws: “System.InvalidOperationException: Sequence contains no matching element”
* This is the same as SQL Server for nvarchar(1234) but SQL Compact also doesn’t support nvarchar(max) as a type
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct
This is about the interaction between partially specified column types and max length settings for string properties. By partially specified column types I mean using just “nvarchar” rather than “nvarchar(x)” where x is max, 4000, etc.
There are regressions from EF5 here.
The interesting lines are bolded below. (Also see triage decisions in the comment below)
__EF5/SQL Server:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct
Column type set to “nvarchar(max)” and no max length
* Same as above
Column type set to “nvarchar(1234)” and any max length
* __Throws: “The Type nvarchar(1234) is not qualified with a namespace or alias.”__
* Interesting that nvarchar(max) is allowed but nvarchar(1234) is not
Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" Nullable="true"
- Correct
* Database
- nvarchar(128)
- __Could be considered correct if 128 is considered the default value in this case__
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- __Correct, but interestingly different__
* Database
- nvarchar(1234)
- Correct
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __Throws from differ after model creation: “Unhandled Exception: System.FormatException: Input string was not in a correct format.”__
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different
* Database
- Throws
__EF6/SQL Server:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct
Column type set to “nvarchar(max)” and no max length
* Same as above
Column type set to “nvarchar(1234)” and any max length
* __Throws: “System.InvalidOperationException: Sequence contains no matching element”__
* The exception is not good, but is thrown for the same reason as the EF5 exception
* __Will file a new bug for this; do not fix as part of this bug.__
Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- __Could be considered correct, but different from EF5 behavior__
* Database
- nvarchar(4000)
- __Again, could be considered correct, but different from EF5__
- __As described in the comments section, this seems like the correct behavior and we will keep it going forward.__
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
* Database
- nvarchar(1234)
- Correct
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __No exception in EF6__
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different as in EF5
* Database
- nvarchar(128)
- __Wrong, but matches EF5 case with nvarchar and no max length__
- __See comments below: this should be fixed to generate nvarchar(4000)__
__EF6/SQL Compact:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="4000" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- As expected for SQL CE due to max length convention
Column type set to “nvarchar” and no max length
* Same as above
Anything that sets column type set to “nvarchar(max)” or “nvarchar(1234)”
* Throws: “System.InvalidOperationException: Sequence contains no matching element”
* This is the same as SQL Server for nvarchar(1234) but SQL Compact also doesn’t support nvarchar(max) as a type
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct
↧
Commented Issue: Code First: setting max length and type to "nvarchar" at same time has unexpected results [1784]
This issue resulted from investigation of https://entityframework.codeplex.com/workitem/1771. The issues are probably related.
This is about the interaction between partially specified column types and max length settings for string properties. By partially specified column types I mean using just “nvarchar” rather than “nvarchar(x)” where x is max, 4000, etc.
There are regressions from EF5 here.
The interesting lines are bolded below. (Also see triage decisions in the comment below)
__EF5/SQL Server:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct
Column type set to “nvarchar(max)” and no max length
* Same as above
Column type set to “nvarchar(1234)” and any max length
* __Throws: “The Type nvarchar(1234) is not qualified with a namespace or alias.”__
* Interesting that nvarchar(max) is allowed but nvarchar(1234) is not
Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" Nullable="true"
- Correct
* Database
- nvarchar(128)
- __Could be considered correct if 128 is considered the default value in this case__
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- __Correct, but interestingly different__
* Database
- nvarchar(1234)
- Correct
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __Throws from differ after model creation: “Unhandled Exception: System.FormatException: Input string was not in a correct format.”__
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different
* Database
- Throws
__EF6/SQL Server:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct
Column type set to “nvarchar(max)” and no max length
* Same as above
Column type set to “nvarchar(1234)” and any max length
* __Throws: “System.InvalidOperationException: Sequence contains no matching element”__
* The exception is not good, but is thrown for the same reason as the EF5 exception
* __Will file a new bug for this; do not fix as part of this bug.__
Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- __Could be considered correct, but different from EF5 behavior__
* Database
- nvarchar(4000)
- __Again, could be considered correct, but different from EF5__
- __As described in the comments section, this seems like the correct behavior and we will keep it going forward.__
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
* Database
- nvarchar(1234)
- Correct
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __No exception in EF6__
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different as in EF5
* Database
- nvarchar(128)
- __Wrong, but matches EF5 case with nvarchar and no max length__
- __See comments below: this should be fixed to generate nvarchar(4000)__
__EF6/SQL Compact:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="4000" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- As expected for SQL CE due to max length convention
Column type set to “nvarchar” and no max length
* Same as above
Anything that sets column type set to “nvarchar(max)” or “nvarchar(1234)”
* Throws: “System.InvalidOperationException: Sequence contains no matching element”
* This is the same as SQL Server for nvarchar(1234) but SQL Compact also doesn’t support nvarchar(max) as a type
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct
Comments: Fixed in changeset de0054f9666d7dae965b17b9d318197965d897d6
This is about the interaction between partially specified column types and max length settings for string properties. By partially specified column types I mean using just “nvarchar” rather than “nvarchar(x)” where x is max, 4000, etc.
There are regressions from EF5 here.
The interesting lines are bolded below. (Also see triage decisions in the comment below)
__EF5/SQL Server:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct
Column type set to “nvarchar(max)” and no max length
* Same as above
Column type set to “nvarchar(1234)” and any max length
* __Throws: “The Type nvarchar(1234) is not qualified with a namespace or alias.”__
* Interesting that nvarchar(max) is allowed but nvarchar(1234) is not
Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" Nullable="true"
- Correct
* Database
- nvarchar(128)
- __Could be considered correct if 128 is considered the default value in this case__
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- __Correct, but interestingly different__
* Database
- nvarchar(1234)
- Correct
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __Throws from differ after model creation: “Unhandled Exception: System.FormatException: Input string was not in a correct format.”__
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different
* Database
- Throws
__EF6/SQL Server:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct
Column type set to “nvarchar(max)” and no max length
* Same as above
Column type set to “nvarchar(1234)” and any max length
* __Throws: “System.InvalidOperationException: Sequence contains no matching element”__
* The exception is not good, but is thrown for the same reason as the EF5 exception
* __Will file a new bug for this; do not fix as part of this bug.__
Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- __Could be considered correct, but different from EF5 behavior__
* Database
- nvarchar(4000)
- __Again, could be considered correct, but different from EF5__
- __As described in the comments section, this seems like the correct behavior and we will keep it going forward.__
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
* Database
- nvarchar(1234)
- Correct
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __No exception in EF6__
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different as in EF5
* Database
- nvarchar(128)
- __Wrong, but matches EF5 case with nvarchar and no max length__
- __See comments below: this should be fixed to generate nvarchar(4000)__
__EF6/SQL Compact:__
Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="4000" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- As expected for SQL CE due to max length convention
Column type set to “nvarchar” and no max length
* Same as above
Anything that sets column type set to “nvarchar(max)” or “nvarchar(1234)”
* Throws: “System.InvalidOperationException: Sequence contains no matching element”
* This is the same as SQL Server for nvarchar(1234) but SQL Compact also doesn’t support nvarchar(max) as a type
Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct
Comments: Fixed in changeset de0054f9666d7dae965b17b9d318197965d897d6
↧
Edited Unassigned: Having System.ComponentModel.DataAnnotations.MaxLength() applied to a string property leads to InvalidCastException exception [1771]
Hi,
I have just tried 6.0.1 version of EF, and it is broken: InvalidCastException is thrown on a string type property annotated with MaxLength() attribute, as in:
[DataType(DataType.MultilineText)]
[MaxLength]
[Column("AdditionalDataSerialized", TypeName = "nvarchar")]
public virtual string AdditionalDataSerialized { get; set; }
It was working in the RC1 version of EF 6.
Following is the code which throws the exception:
public static FacetValues Create(IEnumerable<Facet> facets)
{
FacetValues values = new FacetValues();
foreach (Facet facet in facets)
{
switch (facet.Description.FacetName)
{
case "MaxLength":
values.MaxLength = (int?) facet.Value;
break;
See the (int?) typecast: it fails when the facet.Value is of type System.Data.Entity.Core.Metadata.Edm.EdmConstants+Unbounded.
Regards
Iouri
I have just tried 6.0.1 version of EF, and it is broken: InvalidCastException is thrown on a string type property annotated with MaxLength() attribute, as in:
[DataType(DataType.MultilineText)]
[MaxLength]
[Column("AdditionalDataSerialized", TypeName = "nvarchar")]
public virtual string AdditionalDataSerialized { get; set; }
It was working in the RC1 version of EF 6.
Following is the code which throws the exception:
public static FacetValues Create(IEnumerable<Facet> facets)
{
FacetValues values = new FacetValues();
foreach (Facet facet in facets)
{
switch (facet.Description.FacetName)
{
case "MaxLength":
values.MaxLength = (int?) facet.Value;
break;
See the (int?) typecast: it fails when the facet.Value is of type System.Data.Entity.Core.Metadata.Edm.EdmConstants+Unbounded.
Regards
Iouri
↧
Commented Unassigned: Having System.ComponentModel.DataAnnotations.MaxLength() applied to a string property leads to InvalidCastException exception [1771]
Hi,
I have just tried 6.0.1 version of EF, and it is broken: InvalidCastException is thrown on a string type property annotated with MaxLength() attribute, as in:
[DataType(DataType.MultilineText)]
[MaxLength]
[Column("AdditionalDataSerialized", TypeName = "nvarchar")]
public virtual string AdditionalDataSerialized { get; set; }
It was working in the RC1 version of EF 6.
Following is the code which throws the exception:
public static FacetValues Create(IEnumerable<Facet> facets)
{
FacetValues values = new FacetValues();
foreach (Facet facet in facets)
{
switch (facet.Description.FacetName)
{
case "MaxLength":
values.MaxLength = (int?) facet.Value;
break;
See the (int?) typecast: it fails when the facet.Value is of type System.Data.Entity.Core.Metadata.Edm.EdmConstants+Unbounded.
Regards
Iouri
Comments: Fixed in changeset de0054f9666d7dae965b17b9d318197965d897d6
I have just tried 6.0.1 version of EF, and it is broken: InvalidCastException is thrown on a string type property annotated with MaxLength() attribute, as in:
[DataType(DataType.MultilineText)]
[MaxLength]
[Column("AdditionalDataSerialized", TypeName = "nvarchar")]
public virtual string AdditionalDataSerialized { get; set; }
It was working in the RC1 version of EF 6.
Following is the code which throws the exception:
public static FacetValues Create(IEnumerable<Facet> facets)
{
FacetValues values = new FacetValues();
foreach (Facet facet in facets)
{
switch (facet.Description.FacetName)
{
case "MaxLength":
values.MaxLength = (int?) facet.Value;
break;
See the (int?) typecast: it fails when the facet.Value is of type System.Data.Entity.Core.Metadata.Edm.EdmConstants+Unbounded.
Regards
Iouri
Comments: Fixed in changeset de0054f9666d7dae965b17b9d318197965d897d6
↧
↧
Commented Issue: .RemoveRange does not honour cascade delete [1796]
I have found a bug in removerange and cascade delete in EF 6.0.1.
If I retrieved a list of customers and wanted to remove them and their orders, which are set to cascade delete in both the SQL database and the Model, .RemoveRange does not work on save.
Sample code below:
Dim db as New dbEntities
Dim Customers = db.Customers.Where(function (t) t.LastName="Bloggs").ToList
'This does not work
db.Customers.RemoveRange(Customers)
'This Works
For Each Customer in Customers
db.Customers.Remove(Customer)
Next
Comments: Attaching repro
If I retrieved a list of customers and wanted to remove them and their orders, which are set to cascade delete in both the SQL database and the Model, .RemoveRange does not work on save.
Sample code below:
Dim db as New dbEntities
Dim Customers = db.Customers.Where(function (t) t.LastName="Bloggs").ToList
'This does not work
db.Customers.RemoveRange(Customers)
'This Works
For Each Customer in Customers
db.Customers.Remove(Customer)
Next
Comments: Attaching repro
↧
Commented Feature: Code First: Allow indexes to be specified using attribute/fluent API [57]
"Problem Description:
I'm looking forward to [StoreIgnore] attribute in EF 4 CTP 5. I would like to see a way to create index in table. Something like: [Indexed(Unique=false,Clustered=false)] int A { get; set; } [Indexed(Unique=false,Clustered=false)] int B { get; set; } [Indexed(Unique=false,Clustered=false)] int C { get; set; }"
This item was migrated from the DevDiv work item tracking system [ID=87553].
This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Comments: will the fix works for oracle, mysql, or other database that my has a slightly incompatible sql on creating index?
I'm looking forward to [StoreIgnore] attribute in EF 4 CTP 5. I would like to see a way to create index in table. Something like: [Indexed(Unique=false,Clustered=false)] int A { get; set; } [Indexed(Unique=false,Clustered=false)] int B { get; set; } [Indexed(Unique=false,Clustered=false)] int C { get; set; }"
This item was migrated from the DevDiv work item tracking system [ID=87553].
This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Comments: will the fix works for oracle, mysql, or other database that my has a slightly incompatible sql on creating index?
↧
Edited Issue: Code First: TPC with joins from base class to Identity ApplicationUser Fails [1791]
I have been moving code from EF 5 to a new project using EF 6 and AspNet Identity, and got the following error when trying to enable code first migrations:
"The referenced EntitySet 'Ad' for End 'Ad' could not be found in the containing EntityContainer."
I have a TCP inheritance with a base class (just one! - not the same issue as http://entityframework.codeplex.com/workitem/981) and I have narrowed it down to joining my abstract class ("Ad") to my users ("ApplicationUser") with one-to-many navigation properties. The code works on EF 5.
Simplified (but fully reproducing) code, based on a new MVC Web Application:
using Microsoft.AspNet.Identity.EntityFramework;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Entity;
namespace WebApplication1.Models
{
//You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more.
public class ApplicationUser : IdentityUser
{
//Can't enble this navigation property
//public virtual ICollection<Ad> Ads { get; set; }
}
public abstract class Ad
{
[Key]
[DatabaseGenerated(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.None)]
public int AdID { get; set; }
public string UserId { get; set; }
public string Name { get; set; }
//Can't enble this navigation property
//public virtual ApplicationUser User { get; set; }
}
public class Boat : Ad
{
public int Width { get; set; }
public int Length { get; set; }
}
public class Equipment : Ad
{
public string Description { get; set; }
public int Price { get; set; }
}
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("DefaultConnection")
{
}
public System.Data.Entity.DbSet<WebApplication1.Models.Ad> Ads { get; set; }
public System.Data.Entity.DbSet<WebApplication1.Models.Boat> Boats { get; set; }
public System.Data.Entity.DbSet<WebApplication1.Models.Equipment> Equipment { get; set; }
protected override void OnModelCreating(System.Data.Entity.DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<Boat>().Map(m =>
{
m.MapInheritedProperties();
m.ToTable("Boats");
});
modelBuilder.Entity<Equipment>().Map(m =>
{
m.MapInheritedProperties();
m.ToTable("Equipment");
});
}
}
}
"The referenced EntitySet 'Ad' for End 'Ad' could not be found in the containing EntityContainer."
I have a TCP inheritance with a base class (just one! - not the same issue as http://entityframework.codeplex.com/workitem/981) and I have narrowed it down to joining my abstract class ("Ad") to my users ("ApplicationUser") with one-to-many navigation properties. The code works on EF 5.
Simplified (but fully reproducing) code, based on a new MVC Web Application:
using Microsoft.AspNet.Identity.EntityFramework;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Entity;
namespace WebApplication1.Models
{
//You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more.
public class ApplicationUser : IdentityUser
{
//Can't enble this navigation property
//public virtual ICollection<Ad> Ads { get; set; }
}
public abstract class Ad
{
[Key]
[DatabaseGenerated(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.None)]
public int AdID { get; set; }
public string UserId { get; set; }
public string Name { get; set; }
//Can't enble this navigation property
//public virtual ApplicationUser User { get; set; }
}
public class Boat : Ad
{
public int Width { get; set; }
public int Length { get; set; }
}
public class Equipment : Ad
{
public string Description { get; set; }
public int Price { get; set; }
}
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("DefaultConnection")
{
}
public System.Data.Entity.DbSet<WebApplication1.Models.Ad> Ads { get; set; }
public System.Data.Entity.DbSet<WebApplication1.Models.Boat> Boats { get; set; }
public System.Data.Entity.DbSet<WebApplication1.Models.Equipment> Equipment { get; set; }
protected override void OnModelCreating(System.Data.Entity.DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<Boat>().Map(m =>
{
m.MapInheritedProperties();
m.ToTable("Boats");
});
modelBuilder.Entity<Equipment>().Map(m =>
{
m.MapInheritedProperties();
m.ToTable("Equipment");
});
}
}
}
↧
More Pages to Explore .....
