Hi Angelo, You can’t flatten relationships that way. Flattening relationships only works with Many-to-Many joins where the join table *must have* compound PK made up of the PKs of the two sides of the many-to-many relationship (hence the propagate primary key settings).
You can keep the structure you have and just write cover methods yourself that give you the equivalent functionality of flattening, <my two cents> Or you might want to rethink the design. I’ve found things like Email addresses, Phone numbers and Addresses should not be associated with more than one other object anyway. You will eventually run into the situation where someone wants to change just their billing address and not have that change also impact their shipping or home, or work address. I’ve usually end up having to write a bunch of extra UI code to manage changing just one, or just two of the three, etc. Sometimes proper data normalization is not the right thing to do. Sometimes. I’m not saying that this is always true, but think seriously about what your user’s expectations are around contact management. </my two cents> Dave compound PK On May 20, 2014, at 10:36 AM, Ângelo Andrade Cirino <[email protected]> wrote: > Hi, > > I modeled the following relationships > > Party ->> ContactMechanism -> Email > Party ->> ContactMechanism -> Phone > Party ->> ContactMechanism -> PostalAddress > > And flattened the relationships into Party. My D2W rules are setup so that > this to many relationships are edited with a ERMODEditRelationshipPage > component. The to one relationships from ContactMechanism to the other > entities are optional, since a ContactMechanism can be either an Email, a > Phone or a PostalAddress, but not two of them at the same time. > > I am able to edit the flattened entities but when the Party entity is saved > the following exception is raised: > > IllegalStateException: A valid global ID could not be obtained for entity > named ContactMechanism, relationship named contactMechanisms_phone, primary > key dictionary {partyID = 2; phoneID = 7; }. > at > com.webobjects.eoaccess.EODatabaseContext.databaseOperationForIntermediateRowFromSourceObject(EODatabaseContext.java:4871) > > I've searched the list and there are other similar cases where the solution > was to change the model with the appropriate "owns destination" or > "propagates primary key" properties for the intermediate relationship. From > what I've read, even the delete rule can affect how EO will deal with the > flattened relationships. > > I didn't find a way to set up my model so that EO will handle the flattened > relationships as I want. Or perhaps I am simply trying to do something the > wrong way. Anyway, I need some help. > > Thanx, > > Angelo > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com > > This email sent to [email protected] ————————————————————————————— WebObjects - so easy that even Dave Avendasora can do it!™ ————————————————————————————— David Avendasora Senior Software Abuser Nekesto, Inc.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
