I don't want to use foreign key association to CompanyType (member that will hold the foreign key id) but prefer to use navigation property. So I removed the CompanyTypeId.
I get this exception that relates the relationship between entity Company and CompanyType:
Error 5: The element 'Principal' in
namespace
'http://schemas.microsoft.com/ado/2008/09/edm'
has incomplete content. List of
possible elements expected:
'PropertyRef' in namespace
'http://schemas.microsoft.com/ado/2008/09/edm'.
How can I remove those id's from the POCOs without getting the exception?
This is the difference between Foreign key association and Independent association. Both associations use navigation properties but only Foreign key association uses FK property as well. You can either remove them globally as #Robbie mentioned or you can change the type manually for selected relation.
Select the relation in entity framework designer
In properties remove Referential constraints
Go to Mapping window and map the relation
Here is the screen shot from one of my testing application with one-to-many relation between Order and OrderLine entities:
As you can see there is no OrderId in the OrderLine entity and referential constraints of the relation are empty. Also mapping of the relation is specified.
BUT you can't never remove Id from CompanyType. Ids (PKs) are mandatory. You can only change its accessibility in its properties.
When you imported in your Model from your DB you are asked if you want to:
"Include Foreign key columns in the model"
you need to switch this off.
Related
I think I can illustrate this issue without having to define the classes, as the actual structure beyond the foreign key and navigation properties does not seem to have any bearing.
In my derived EntityTypeConfiguration class, Entity Framework will let me do this if I want a 1-many relationship with no FK property defined:
HasRequired(r => r.Foo)
.WithMany(); //No explicit foreign key property, navigation property only
If I want a 0..1-many relationship, I can do this with an explicit nullable FK property, for instance public int? Foo_Id {get; set;}:
HasOptional(r => r.Foo)
.WithMany()
.HasForeignKey(r=>r.Foo_Id); //Nullable explicit foreign key property and navigation property
but I cannot configure a 0..1-many relationship without an explicitly defined FK property the way I can with a 1-many relationship:
HasOptional(r => r.Foo)
.WithMany(); ////No explicit foreign key property, navigation property only, causes runtime error
The error I receive on the last example is something akin to this:
Multiplicity conflicts with the referential constraint in Role 'Bar_Foo_Target' in relationship 'Bar_Foo'. Because all of the properties in the Dependent Role are non-nullable, multiplicity of the Principal Role must be '1'.
It seems pretty apparent that the error doesn't match the mapping. I know that this can pop up if you try to configure a 0..1-many relationship where the FK property is not made nullable, but that's not the case here, because there is no FK property defined on the class.
Am I missing something? Is this a bug? Why can I configure a 1-many relationship and EF successfully deduces the FK, but on a 0..1-many it craps the bed without an explicitly defined nullable FK property on my class?
I have a DBFirst EntityFramework 6.1 solution that i'm trying to generate off of. When i add a table that only contains two foreign keys the table is turned into two associations and I can not directly access the table anymore. This is neat for navigation in the code but makes it a pain in the ass to delete records from the table.
Is there a way to prevent this behavior and gain direct access to the table as an entity?
For example i am unable to remove an entry in the association because i get this error
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.
For example here is how my database sees the structure.
Here is how it appears in entity framework. Notice that the CorporateDataShareVisible table is missing and instead two new associations are created.
The CorporateDataShareVisible table should be able to be deleted and added to at will but any changes i make seem to stop it from working.
Add a primary key to your table that has only foreign keys. EF uses the primary key to keep track internally of the element. Without a primary key it doesnt know which element was modified and how to send that back to your RDBMS.
I prefer surrogate keys i.e auto incrementing integers.
You can also add the primary key by making it a composite key of both the foreign keys
For some reason I had my made my mind a while back on an EF 6 project that I would try to avoid naming foreign keys. I defined much of the model without testing it incrementally and so I have been running into multiplicity and incomplete Fluent API definition issues:
A relationship from the 'User_InternalAuth' AssociationSet is in the
'Deleted' state. Given multiplicity constraints, a corresponding
'User_InternalAuth_Target' must also in the 'Deleted' state.
In one case, here is the code:
nModelBuilder.Entity<User>()
.HasOptional<InternalAuth>(u => u.InternalAuth)
.WithRequired(a => a.User)
.WillCascadeOnDelete(true);
My understanding is that it is saying:
The entity User
Has an optional property InternalAuth of type InternalAuth
On the other end, InternalAuth has a required property User, so that all InternalAuths have Users but Users may or may not have an `InternalAuth.
If the User gets deleted, so does his InternalAuth if he has one (does this override an optional behavior of treating optionals like nullables?)
However when I try to delete a User I receive an exception about the multiplicity of some association between InternalAuth and User.
Is it true that if EF understands the multiplicity of a relationship there is a way for it to provide it a unique column name for it so there is a canonical naming convention?
If so, do you ever really need to define foreign keys explicitly by annotating the model or through Fluent API?
If not, is it a worthwhile or advisable thing that I should keep trying to avoid it? (I'm thinking along the lines of migrating the data model, database administration, any EF quirks)
Why does attempting to delete the relationship above violate a multiplicity constraint? What else does it need to know?
assuming that
You can configure cascade delete on a relationship by using the WillCascadeOnDelete method. If a foreign key on the dependent entity is not nullable, then Code First sets cascade delete on the relationship. If a foreign key on the dependent entity is nullable, Code First does not set cascade delete on the relationship, and when the principal is deleted the foreign key will be set to null.
My guess is the following : the FK is nullable so the fact to set it to null with the required constraint causes the rise of the exception.
One solution is to put the FK in the PK, that is add, in InternalAuth, the FK to User in the PK. Doing this will mark the entity as deleted when setting a part of his PK to null.
Im trying to generate a model from a database. The model is being generated but all the foreign key fields (that should be only navigation properties) are being mapped as Navigation Property and a scalar property (IN THE MODEL).
I know the foreign key is added in the end of the multiplicity on database but whenever I generate a database from model, all the entity classes doesn't contain that field.
Is there a way to ignore this field generating the model from database?
When you generate the model from the database there is a check box called Include foreign key columns in the model. This check box is by default selected. If you deselect it your model will not contain foreign key properties but just navigation properties.
I am trying to make Entity Framework inheritance between two tables.
The parent:
ParentTable
Id: int primary key
CustomAttribute: int
The Child:
ChilTable
Id: int primary key (not the same one as the parent, Child specific Id)
TCId: int foreign key to parent
SomeInformation: String
For some reasons I want to keep naming "Id" the primary key of both the ParentTable and the ChildTable. That should not bother EntityFramwork as I created a custom property with another name "CId" for the child Table:
And the Child1 table mapping is the following:
But when I "Validate" the model, VS2010 says...:
Error 3002: Problem in mapping fragments starting at line 103:Potential runtime violation of table Child1's keys (Child1.Id): Columns (Child1.Id) are mapped to EntitySet Parents's properties (Parents.CId) on the conceptual side but they do not form the EntitySet's key properties (Parents.Id).
Basically, I understand that Entity Framework sees a problem in the fact we map a table's primary key to a property that's not the key of the Entity but then how are we supposed to use inheritance?
IS inheritance only allowed when there is no primary key in the "Child" table? Should I but my primary key as "simple key"?
Thanks in advance...
EF expects the child's Id PK to also be a FK to the parent. So Child.Id is both a PK and an FK.