I've got database tables like this:
A person may be a member of many teams. A team may have many members. Each person may have a position (think job title) within the team.
I've tried to set this up with ADO.NET Entity Framework and get errors:
Error 3021: Problem in mapping
fragments starting at line ... Each of
the following columns in table
Membership is mapped to multiple
conceptual side properties:
Membership.PersonId is mapped to
<MembershipPerson.Membership.PersonId,
MembershipPerson.Person.Id>
and
error 3021: Problem in mapping
fragments starting at line ... Each of
the following columns in table
Membership is mapped to multiple
conceptual side properties:
Membership.TeamID is mapped to
<MembershipTeam.Membership.TeamId,
MembershipTeam.Team.Id>
The primary key of my Membership entity is a compound key of two foreign keys. I think that's the problem.
What must I do differently?
This happens if you use independent association on the property which is both part of primary key and foreign key. EFv4 introduced Foreign key associations (the difference is described here) and once you expose foreign key in the entity you must define foreign key association. After defining referential constraints delete mapping of independent association in Mapping details window.
Related
I am using Spring data JPA(Hibernate).
I am trying to join my tables (Table A & Table B) but on Non-Primary Columns. Is it possible to actually do that? I am trying to use referenceColumnName, but it seems to not working, giving error :
Cannot set int to Integer.
When I am removing referenceColumnName, then it is working but obviously it is joining with Primary Key. Also in case of One-to-one Bidirectional, where should I place mappedBy & JoinColumn?
The annotation #JoinColumn indicates that this entity is the owner of the relationship (that is: the corresponding table has a column with a foreign key to the referenced table), whereas the attribute mappedBy indicates that the entity in this side is the inverse of the relationship, and the owner resides in the "other" entity.
Regarding the other question of using joining tables on Non-Primary columns, there are plenty of threads why don't you go through. for example
Does the JPA specification allow references to non-primary key columns?
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
I have a Database model like this
FlowObject
FlowObjectID (PK)
Description
Active
ProcessObject
FlowObjectID (PK, FK)
HasSubmit
DecisionObject
FlowObjectID (PK, FK)
YesFlowObjectID (FK)
NoFlowObjectID (FK)
YesCaption
NoCaption
When I try and use create my Entity model I get this warning in my project.
Foreign Key constraint 'FK_ProcessObject_FlowObject1' has been omitted from the storage model. Column 'FlowObjectID' of table 'Investigations.Store.ProcessObject' is a Foreign Key participating in multiple relationships. A one-to-one Entity Model will not validate since data inconsistency is possible.
???
Why did it drop my foreign key? Because "A one-to-one Entity Model will not validate since data inconsistency is possible."
So it sounds like it is saying it dropped the FK because of data inconsistency but dropping the FK actually reduces date consistency?
Should I redesign my database? Is there anyway for L2E to handle FK's that participate in multiple relationships? Is it considered bad database design to have FK's that participate in multiple relationships?
What you've described, translated to object-oriented terms, is that a FlowObject contains an optional ProcessObject and an optional DecisionObject. If this is what you actually meant, the database schema is correct.
If you're trying to have ProcessObject and DecisionObject extend FlowObject, inconsistency is possible because both the ProcessObject and DecisionObject rows may exist. To eliminate the inconsistency, the union-subclass modeling technique is appropriate: only ProcessObject and DecisionObject tables exist, each containing all relevant fields, and FlowObject, as an abstract base class, becomes a view consisting of the union of the common base fields between the two tables.
I have just get the same error when trying to refactor this. In EFv1 (.NET 3.5) this cannot be solved. In EFv4 (.NET 4.0) you can change independent association (the only association/relation available in EFv1) to foreign key association and it will work. But FK associations have some other drawbacks so it is not a silver bullet.
I'm evaluating using EF against an existing schema - the problem is that I can't work out how to set up associations between tables where the foreign key is NOT the primary key of the master table.
As an example, a foo may have many bars as defined like this (forgive the pseudocode):
table foo {
int foo\_id pk,
char(10) foo\_code,
...
}
table foobar {
int bar\_id pk,
char(10) bar\_foo\_code fk(foo.foo\_code),
...
}
What am I missing to be able to create the foo_foobar association, and hence a Bars navigation property on the Foo entity?
Linq to entities doesn't support Foreign Keys which don't point to the primary key of a table (see log message 3). Linq to entities will treat it as a normal field on a table. You won't be able to navigate to the entity it's linked to.
If you have an existing schema i'd recommend using the edm generator as this will create the EMDX file, code behind and even the view code (which can be very large). If your existing scheme is quite large Check out this post, which explains how to deal with large schemas.
When you run the EDM Generator you'll find out all the things that are not supported.
Looking at a previous EDMGen2.exe log we got the following types of messages back:
The data type 'sql_variant' is not
supported, the column 'ColumnName'
in table 'TableName' was
excluded.
The table/view 'tableName' does not
have a primary key defined. The key
has been inferred and the definition
was created as a read-only table/view
The relationship 'RelationshipName'
has columns that are not part of
the key of the table on the
primary side of the relationship
which is not supported, the
relationship was excluded.
We've also found that the Linq project actually crashed Visual Studio quite alot as the code file produced by EDM was well over 80 mb.