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: Sat, 16 Apr 2005 20:19:52 -0400
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
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