Re: Bi-directional One-to-one relationship
Re: Bi-directional One-to-one relationship
- Subject: Re: Bi-directional One-to-one relationship
- From: Drew Thoeni <email@hidden>
- Date: Sun, 17 Apr 2005 20:46:53 -0400
Well, now that makes a lot of sense. Thanks for the clarification. Yes,
in my example, while it is o-o, the empPhoto would not exist unless the
employee did. In your example, I can see each would have a different
primary key, and use a foreign key for describing the relationship.
regards,
Drew
On Apr 17, 2005, at 1:57 AM, Arturo Pérez wrote:
On Apr 16, 2005, at 8:19 PM, Drew Thoeni wrote:
Perhaps the difference comes in what EOF assumes is proper and what
I'm describing. The only time it seems to make sense to me to have a
o-o relationship is, for example, a security database for employees.
Each employee has a row and, since we don't want to query on their
photos, we make a separate table for their badge photo. So, the PK
could (and I think should) be the same, let's say the employee ID.
Two tables then exist, employee and employeePhoto, each has a PK of
the employee id and they are o-o. The PK in employeePhoto becomes the
FK to employee also.
Does that makes sense in EOF to do it that way?
Drew
Hi Drew,
In the employee & photo example the photo can never exist without an
employee.
That's the second case I describe below where you set Owns Destination
and Propagates Primary Key.
But can you think of an example where two entities have the same
primary key and one can exist without the other?
An example of one-to-one relationship where you don't propagate & own:
A Driver and a Vehicle. Driver can drive only one Vehicle at a time
and vice versa. But regardless of whether a Driver is driving or a
Vehicle is being driven they both still exist; that is just because a
Vehicle doesn't have a Driver doesn't mean you should delete it from
the database.
-arturo
On Apr 16, 2005, at 3:46 PM, Arturo Pérez wrote:
HI all,
That's horrible - that's not the way it works - stop now - please!
Ok, now that I have that out.
You have two entities, Data and State. If they are related and
distinct (that is, they can exist separately) then one of them must
have a foreign key to the other. You can give them the same primary
key if you want but I'm not sure why you would want to.
So, Data has a PK of pkData and State has a pk of pkState and a
foreign key of fkData (or the other way round, depends on what
you're doing). Then you cntrl-drag from pkData to fkData and you
have your one-to-one bidirectional relationship.
Now, in some cases, they may have the same primary key. I can't
think of any situation where that makes sense other than where one
may not exist without the other. In that case you set the Owns
Destination and Propagates Primary Key flags on one of them.
Remember EOF assumes a properly defined relational schema (using its
own definition of properly). What Drew described doesn't really
fall into that category :-)
-arturo
On Apr 16, 2005, at 11:50 AM, Des Oates wrote:
Hmm so what you're saying is that if the primary keys in each
object have the same name, then you can do this? I never would
have thought that that would work but I''ll definitely give it a
try. Thanks for the tip.
Des
On 16 Apr 2005, at 16:30, Drew Thoeni wrote:
First let me preface by saying I'm an effective novice when it
comes to WO, though I've been tinkering for a couple of years.
That being said, in my limited experience, generally you have a
o-o relationship where EO1 and EO2 have the same primary key. I
usually split a single table because of a BLOB or some such that I
want to avoid referencing unless needed.
If I'm reading this right, your primary keys are PKData and
PKState. I think the key should be the same in both tables, and
skip having the separate foreign key.
So, DataEntity and StateEntity would both have a primary key of
and PKState, and you'd control drag from PKState to PKData,
selecting "to-one" in the inspector.
I'm pretty sure that would work and have done it in the past. I'd
try it now but can't launch EOModeler due to 10.3.9 update :(
Drew
On Apr 16, 2005, at 10:14 AM, Des Oates wrote:
OK Sorry for not being clear, Here's an example.
I created 2 new EOs in a fresh EO model. DataEntity, and
StateEntity.
In each a put a couple of Attributes and integer primary keys,
PKData, and PKState respectively
To create a relationship I first copy PKState attribute, and
paste it into DataEntity. I then cntr + drag from
StateEntity.PKState to DataEntity.PKState.
By default that creates a One-to-many relationship. It inserts
the relationship properties 'stateentity' and 'dataentitys' into
DataEntity and StateEntity respectively.
I want to change this so I highlight StateEntity.dataentitys and
open my inspector. I change the 'To Many' property to 'To One'
in the relationship's inspector.
I also set its optionality to 'Mandatory' and its delete rule to
no action.
On the other side of the relation ship (DataEntity.stateentity) I
also set the optionality to Mandatory, set the delete rule to
'cascade' and the tick the 'owns destination'
If at this point I want to check the consistency of the model. I
go to the Model Menu, and hit the 'Check Consistency' menu. This
reports the following problem:
Relationship dataentitys in entity StateEntity is a to-one
relationship, but its destination attribute(s) does not match the
primary key of the destination entity.
Is this something I can live with? I don't believe so, since
later on I get runtime errors when these objects are created
relating to null primary keys, OR duplicate primary keys being
created. I also get runtime errors if I create 2 independent
and opposing unidirectional to-one relationships.
The only way I can get a one-to-one relationship to work is if I
delete the relationship on the destination, which in this case
would be 'StateEntity.dataentitys'. Then it works but of course
its now unidirectional. I.e. I can't navigate to my DataEntity
from my StateEntity. I want to be able to navigate to and from
either object.
Sorry for being long winded, but that's about as concise as I
could make it.
Des
On 16 Apr 2005, at 13:07, Drew Thoeni wrote:
If you are talking about setting up a o-o relationship, then yes
EOmodeler will do this. Create the two tables, ctrl-drag from
the primary key in one to the PK in the other and in the
resulting window, click "to one".
I suspect you are, though, asking a more complex question. If
you are, perhaps you can clarify with an example.
Drew
On Apr 16, 2005, at 8:01 AM, Des Oates wrote:
Does anyone know if EO Modeler supports a one-to one
relationship where each related object is referenced as a
property in the other? I've been trying to set up my EOModel
like this for a while now, but no matter which way I try to do
it EO Modeler complains.
A use case of this would be if you have a single data object,
linked to its corresponding single state object. In O-O you
would want to keep the logic handling these separate. (I.e. 2
different classes)
I ended up working around this so its not a showstopper for me
but I'm just curious for future reference if anyone's actually
managed to do it, and if so how.
thanks
Des
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list
(email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden