By looking at your Entity Modeler screenshot again your relationship
from Entry to EntryScore should have "id" as source attribute and not
your entryScoreID (finally you want your PK to be propagated).
Changing this you should not have any warnings when deleting
entryScoreID.
jw
Am 03.06
Jeff,
a 1:1 always connects the pk of both tables. Otherwise it is 1:n and
should be modeled that way.
You have modeled a 1:n and set the propagation in the wrong direction
(assuming that the other side has a to-many relationship :)
If you want to delete the entryScoreID you have to corre
HI Alexander,
So, to "propagate primary key" between two entities that have a
"one to one" relationship, how would need to specify that? As noted
in my recent message, I set "propagate" on the relationship in the
relationship editor, but the foreign key remains in Entry with no
seeming
When I try to delete the foreign key, I get a big error message:
<>
If the relationship is setup as a "propagate primary key", why should
the relationship be referencing it?
Then, when I select Delete Anyway, it deletes both the foreign key AND
the relationship. Now what?
Thanks,
Jef
Yes, I had wondered about that myself. The foreign key is a product
of the GUI as when you create a new relationship, there is no way
(that I could find) to specify initially that you want it to
propagate the primary key, so its created initially whenever you
create a new relationship. T
Jeff,
you don’t want to propagate anything here.
entryScoreID is not a primary-key but a foreign-key, so you can not
propagate it.
Owns Destination is wrong as well. You designed your relationships
backwards (read: wrong).
And you’ll need to set all other relationships as well before you
sa
Why do you have the attribute "entryScoreID" in the Entry entity? If
you make a to-one relationship Entry->EntryScore and propagate the PK
you only need an FK attribute in EntryScore that gets set to the PK of
Entry by EOF.
In your exception it is complaining about the entryScoreID from Entry
On Jun 2, 2008, at 9:42 PM, Jeff Schmitz wrote:
thanks!
You're exactly right, that relationship is an owns destination
relationship. I changed the code to set the properties on the
existing entryScore instead of creating a new one:
EOQualifier poolQual = Pool.NAME.eq(name);
pool
thanks!
You're exactly right, that relationship is an owns destination
relationship. I changed the code to set the properties on the
existing entryScore instead of creating a new one:
EOQualifier poolQual = Pool.NAME.eq(name);
pool = Pool.fetchRequiredPool(ec, poolQual);
entry =
Hi Jeff,
what is your entryScore relationship like? Do you have "owns
destination" checked? If yes then by creating an Entry object EOF does
create an EntryScore object for you automatically. So when you save
changes that object is still in the editing context but no attributes
have been
10 matches
Mail list logo
