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 protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>> >>> This email sent to [email protected] >> >> -- >> 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 protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >> >> This email sent to [email protected] > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
