Re: join entity with extra info, is this possible?
Re: join entity with extra info, is this possible?
- Subject: Re: join entity with extra info, is this possible?
- From: Ray Kiddy <email@hidden>
- Date: Fri, 5 Nov 2010 11:17:30 -0700
On Nov 5, 2010, at 10:26 AM, Mike Schrag wrote:
> the relationship wizard in entity modeler should set both of these variations up for you automatically if you pick "To Many" on both sides and turn on and off the "flatten relationship" checkbox ...
>
> ms
>
Hm. I will check that out.
> On Nov 5, 2010, at 12:51 PM, Chuck Hill wrote:
>
>> Are the relationships to the join entity marked as propagates primary key?
That may be the thing. It seems odd that, since I am setting both columns that constitute the primary key, I would have to set something on the relationship which says "oh and by the way, I am propagating the primary key." I mean, I am, myself, propagating it when I set the relationships which set the primary key values. This seems to be a very circular statement....
And I am seeing now that if I use WOLips and have it create a many-to-many relationship for me, either flattening or not, I do get the 'propagate primary keys' on the relationships checked.
Yet, when I create a many-to-many relationship by hand that is normally flattened, and I often do this, I do _not_ check the 'propagate primary keys' on any of the relationships. And there is no problem with this.
Logically, when I am using a join table with no class property relationships and flattening relationships, and when I am using a join table with class property relationships and no flattened relationships, the behavior of the primary key setting should be the same. But it is not. The fact that these behaviors are different is, I can argue, a bug. But it is a fairly subtle problem. I do not like relying on tools to do the right thing, so perhaps there should be a validation warning when 'propagate primary keys' are not properly set. Or my case, without 'propagate primary keys', should work. Hm. Not sure.
Anyway. Off to do actual work....
- ray
>>
>> On Nov 5, 2010, at 9:25 AM, Ray Kiddy wrote:
>>
>>>
>>> I keep trying to do this. It never works. I cannot see why, but I bump into it every once in a while and then I go ahead and do what I think is the not-so-smart thing and that works, so....
>>>
>>> Can anyone explain how this might be made to work? Or explain why it cannot? Either I have a blind spot in my knowledge of EOF, or this is a bug. Or both.
>>>
>>> We all know the classic join entity used in a many-to-many relationship. Two columns, both part of the primary key, the relationships are not class properties, and relationships are flattened across the join from both sides. Tools often have a problem setting this up right, but if you do it enough, you can do this manually with your eyes closed.
>>>
>>> But what if one wants a class property in the join?
>>>
>>> some_thing other_thing thing_join
>>> ----------- ----------- ------------------
>>> s_pk | name o_pk | name s_pk | o_pk | name
>>>
>>> I keep thinking that I can:
>>>
>>> 1) set up all the relationships in the exact same way one does it for a many-to-many, except
>>>
>>> 2) all the relationships are class properties
>>>
>>> 3) nothing is flattened, but one instead can use valueForKeyPath across the join.
>>>
>>> I can manually create the join table, insert data into the join table with SQL, and everything works great. I can use these in an app and they work fine. The problem is that I can never seem to create one of the joins in an app. I always get an error upon saving saying that primary key values are not set for the join entity. But I can:
>>>
>>> 1) create the join EO
>>> 2) call addObjectsToBothSidesOfRelationship on someThing, pointing it to the join object.
>>> 3) call addObjectsToBothSidesOfRelationship on otherThing, pointing it to the join object.
>>> 4) call takeValueForKey on someThing, giving it the join object.
>>> 5) call takeValueForKey on otherThing, giving it the join object.
>>> 6) call addObjectsToBothSidesOfRelationship on the join object, pointing it to the one of the objects and then again with the other.
>>> 7) call takeValueForKey on the join object, giving it one of the other objects, and then again with the other.
>>>
>>> I have tried this with objects that are EOGenericRecords, with objects that are custom EO classes, and every variation of these that I could think of. And I can do all of these method calls and any combination of them and I think I have tried them all and I can never, ever get it to work.
>>>
>>> But if both sides of all the relationships are set, the two pk column in the join table _have_ values. They _are_ a unique pair. They _should_ constitute a primary key.
>>>
>>> Yet, I _always_ end up creating an extra column just for a unitary primary key in the join table. But this feels unnecessary and wrong. This _should_ work.
>>>
>>> Any suggestions?
>>>
>>> - ray
>>>
>>> _______________________________________________
>>> 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
>>
>> --
>> Chuck Hill Senior Consultant / VP Development
>>
>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
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