Apple

On May 20, 2014, at 9:59 PM, Ângelo Andrade Cirino <email@hidden> 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@hidden>:

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@hidden> 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@hidden)

This email sent to email@hidden

—————————————————————————————
WebObjects - so easy that even Dave Avendasora can do it!™

—————————————————————————————
David Avendasora
Senior Software Abuser

Nekesto, Inc.

References:
	>Global ID problem with flattened relationship (From: Ângelo Andrade Cirino <email@hidden>)
	>Re: Global ID problem with flattened relationship (From: David Avendasora <email@hidden>)
	>Re: Global ID problem with flattened relationship (From: Ângelo Andrade Cirino <email@hidden>)
	>Re: Global ID problem with flattened relationship (From: David Holt <email@hidden>)