Re: Bi-directional One-to-one relationship
Re: Bi-directional One-to-one relationship
- Subject: Re: Bi-directional One-to-one relationship
- From: Des Oates <email@hidden>
- Date: Mon, 18 Apr 2005 21:02:44 +0100
Hi Arturo,
Thanks for the follow up. I started from scratch again and followed your steps, and apparently I get a different outcome than you do. I put some comments inline on that, but its not so relevant now, since in the process of doing this, I got to the bottom of my problem.
What I think the problem I have is, is the EOModeler consistency check itself. I didn't notice that 'Valid Relationships' is a Consistency Check preference setting in EOModeler (On Mac anyway). So if it's turned off, everything looks and works fine. I had been assuming this consistency error was a showstopper but of course it's not. Indeed from an RDB, perspective, this scenario is probably worth flagging as a warning, even though its perfectly valid in O-O land.
Thanks for the contributions.
Des
On 18 Apr 2005, at 15:43, Arturo Perez wrote:
Des Oates wrote:
But isn't this then identical to the original scenario that I have that gives me Model validation errors?
Des
Hi Des,
I'm not show who you are responding to. But I can assure you that I set up one-to-one relationships all the time without running into the issues that you mention.
Going back to your example. (note I haven't done this recently (i.e. last month or so) so I may get some UI details incorrect.)
You have 2 RDBMS tables: TheData and TheState. Each has its own PK: pkData, pkState.
Now, with the above what is the relationship between the two tables? No way of knowing. Does either have a foreign key to the other? I can't see one.
Well actually there was one there, I just didn't describe it very well. In my initial steps, I copied the primary key from TheState, and pasted it into TheData. This was what I would use as my foreign key. However, that was poorly described originally.
If you truly require a one-to-one relationship then one of the tables must contain a foreign key to the other but that's not described above.
OK, so I started again with a blank EO model, and followed your steps...
Let's assume that TheState needs one TheData. So we create a FK in TheState referencing TheData's PK and call it fkData.
Now we turn to EOModeller. We create 2 entities called DataEO and StateEO. We give them all the necessary attributes and the 3 keys described above: pkData, pkState, fkData.
OK So far
We turn the black diamonds off for all three (no need for them in the entities - they are RDBMS artifacts).
OK to here too
We cntrl-drag from fkData to pkData and we have our one-to-one relationship, bidirectional by default.
This is where I start to deviate. I don't get a 1-1 relationship by default. I get a 1-many by default, where 1 'TheData' maps to many 'TheState's
Also by default (I think) it's mandatory; optional one-to-ones require something special handling.
In my EOModel, both generated relationships (TheData.states, and TheState.data) are optional.
So now if I change the 'state's relationship in theData from 'To Many' to 'To One' I get the following consistency error irrespective of how I set any of the advanced relationship settings for either relationship.
<<<Relationship
states in entity
Data is a to-one relationship, but its destination attribute(s) does not match the primary key of the destination entity.>>>
I think where you're going wrong is just setting up a relationship between two arbitrary primary keys. But such a thing is meaningless in and of itself.
On 18 Apr 2005, at 01:46, Drew Thoeni wrote:
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:
This email sent to email@hidden