Hi, 

I am not really clear about your datamodel - and I think some of your problems 
might come from that (please bear with me, I may be completely wrong about your 
business logic). Couldn't you change your model to something like this:

Party ->> ContactMechanism (optional)

ContactMechanism->ContactMechanismType (mandatory)
ContactMechanism->ContactMechanisUsage (mandatory)

I deliberately wrote the above on two different lines to make things clearer.

ContactMechanism could have one String attribute that can hold an email 
address, a phone number, anything. It's interpretation is according to the 
mandatory to-one ContactMechanismType, it's usage (home, work, etc) is governed 
by the mandatory to-one ContactMechanismUsage.

I think this model covers everything you want (unless I completely 
misunderstand your problem), it is properly normalized. And it should work 
nicely with D2W.

Hope this helps
---markus---

On 20.05.2014, at 16:36, Â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/mailinglists%40kataputt.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]

Reply via email to