Hi Dave, Thank you for your help. I was led to think that a one to many relationship could be flattened like a many to many can. Proved is I was wrong assuming it.
Regarding the model I am trying to implement, I am modeling my application after Len Silvertston's book, "The Data Model Resource Book". I regard his models and suggestions very valuable. This specific model, Party ->> ContactMechanism -> Email or -> Phone or -> PostalAddress suits my needs very well. The different uses of addresses or phones will be modeled with another entity, ContactMechanismPurpose, which the user can change as needed. So when a user wants to change a billing address it will be a trivial change in the relationship ContactMechanism -> ContactMechanismPurpose. Currently, I have not yet implemented the contact mechanism purpose entity, but I have implemented ContactMechanismType, where the type can be phone, FAX, business email, home email and so on. My problem with this approach is that I want to rely on Modern D2W to build my application without writing custom components if possible. In the case of the to many and optional to one relationships Party ->> ContactMechanism -> Email I am very frustrated for not being able to find a way to use one of the most wonderful components in Wonder, ERMODEditRelationshipPage. I accept suggestions on how to instruct ERMODEditRelationshipPage to create the whole entities path to solve models like Party ->> ContactMechanism -> Email. As a matter of fact, I've been thinking of writing a custom component to edit relationships to entities like phones and emails like the UI in the iPad "Address Book". The way it uses the small + and - buttons and the popup for the type is very inspiring. Angelo 2014-05-20 17:24 GMT-03:00 David Avendasora <[email protected]>: > 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]
