I have an entity which has several foreign keys (int) .
I want to check if the Foreign Key Objects exists in the DB.
I want to do it as much generic as possible, so i won't need to check for each entity it's navigation properties
Related
Some of my entities have navigation properties as they have a foreign key to another entity in the database. In my code, I've set the primary keys of the navigation properties to link the entities with each other.
The problem is that entity framework sees this as a new entity and tries to add it to the database with next error as a result:
Cannot insert explicit value for identity column in table 'xxx' when IDENTITY_INSERT is set to OFF.
Obviously, because the entity is new and not acquired from the database.
Is there a way in EF to remove the tracking of the entity?
Are there ways to make one-to-many (abstract) relation without using SQL foreign keys?
I know it could be made by joining 2 non-related tables. But is it possible to use EF Core default navigation tools?
I think you want that because you can't add a foreign-key to your entity
So, you can solve that so:
You have a entity
Group
and you want a
List<User>
but your User can't be assigned to one group.
So you create a
GroupUser
entity which has a foreign key for the
List<GroupUser>
and a navigation property to the User
This is called a many-to-many relationship
Is there a way to map multiple foreign keys to the same navigation property of an entity? I have a table with a self-referencing many to many relationship defined by a relationship table.
For example, I have a Person table and I want to define the different related people. I created another table, PersonRelationship, that defines those relationships with 2 foreign keys to the Person table. It doesn't matter if the person is referenced in the first or the second foreign key just that the person is in one. I would like my Person entity to have a list of all the relationships but instead it has two lists of relationships: one in which the person is in the first foreign key and another where it is the second foreign key.
How can I map these two foreign keys so that they map to the same list in the Person entity? (I am using a database first approach)
I have a database that has a table with a 2-column primary composite key (one int, one bigint.) I have two tables that have a composite foreign key, referencing the first table's composite primary key. The relationships are (as far as I know,) fine and dandy on the database itself.
When generating a DB context via DB-first EF6, these relationships/navigation properties are not represented in the generated models (No virtual members in the two child tables referencing the parent table.)
Since it's db-first, I can't modify the models.
In this case you can put those relationships into the onmodelcreating function in db context. We can put constraint there.
Is it possible to create associates b/t 2 non-key fields in the Entity Framework?
Example: Take the 2 tables in a legacy application (i.e. keys/structure cannot change)
Order (
OrderId : int : PK
OrderNo : varchar
)
OrderDetails (
DetailRecordId : int : PK
OrderNo : varchar
)
In the Entity Framework, I want to create an association b/t Order and OrderDetails by the OrderNo field, which is not a primary key on either table or a FK relationship in the database.
This seems to me as not only should it be easy to do, but one reasons to use something like EF. However, it seems to only want to allow me to create associations using entity keys.
The Entity Framework allows you to claim that columns are keys and that FK constraints exist where none actually exist in the database.
That is because the SSDL (StorageModel part of the EDMX) can if necessary be manipulated by you and lie about the database.
The EF will then interact with the database as if the keys and foreign keys really do exist.
This should work, but all the normal caveats about referential integrity apply.
See my Entity Framework Tips
Hope this helps.
The problem with using non-key fields to define relationships is that the keys are not guaranteed to be properly navigatable. That could lead to a situation where you have a one to one relationship between two entities where there are more than one possible rows that fufill the relationship.
...when relating data from a database, the relationships should always be based on keys. The keys enforce the referential integrity.
One more workaround:
create view vOrder which will not include PK and create Entity from it.
Set PK in this entity to OrderNo
Now you will be able create association