To get this to work with D2W it sounds like you may want to focus on the ContactMechanism entity and create your relationships from there.
Sent from my iPad > On May 20, 2014, at 9:59 PM, Ângelo Andrade Cirino <[email protected]> wrote: > > 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/programmingosx%40mac.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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
