Apple

On 2009/03/24, at 17:55, David Avendasora wrote:

Hi Paulo,

Personally, I really dislike compound PKs, but there's no real reason not to use them for tables that exist simply for the purpose of establishing a mant-to-many relationship.

On Mar 24, 2009, at 1:07 PM, Paulo Filipe Andrade wrote:

1 ==
In the "deprecated" EOModeler User Guide it states:
" Primary key propagation is also commonly used to generate primary keys for join tables in many-to-many relationships."

If the join table has a compound primary key (consisting of the two foreign keys to User and Message), how does this apply?

Well, if you didn't have compound PKs, then you really couldn't propagate PKs on a to-many relationship.

Since both to-one relationships on the join are required, it will simply propagate both of the PKs of the User and Message into the join table.

2 ==
Does anybody know how does WebObjects manage flattened relationships internally?
Basically I want to know if (besides having more readable code) I get some performance improvements using this.
So which are there any performance differences in these two?

user.messages();
or
user.userMessages().valueForKey("message");

I don't think there's much difference at all, but Someone more versed in the depths of EOF can probably answer for sure (Chuck?).

3 ==
Now imagine I need to know if a user has read a message. I would simply add a boolean to the indirection table to store this.
Can I still use the flattened relationships WebObjects provides and store this boolean in the indirection table?
Are there any caveats I should be aware of?

Well, at the point something is no longer purely a join table, it takes on business meaning and I would recommend having the table have it's own distinct primary key.

Is there a technical reason behind your recommendation or just personal preference?

4 ==

Theoretically if a message has no relation to users, it should be deleted.
Does Owns Destination work in this many-to-many scenario?

This doesn't sound right. If this relationship designates messages that have been read by users, then you are saying that a message that hasn't been read doesn't exist. While this is an interesting philosophical idea, I don't think it really translates into the real world. Can't you have unread messages?

This is unrelated to the read/unread messages. The idea is simple, if a Message is no longer referenced by any User it should be deleted.

So if userA and userB are the only ones that have a relation to messageA

userA.removeObjectFromBothSidesOfRelationshipWithKey(messageA, "messages");

userB.removeObjectFromBothSidesOfRelationshipWithKey(messageA, "messages");

editingContext.saveChanges();

At this point messageA would be deleted.

5 ==

Not directly related to this scenario but I still couldn't quite figure out:

When doing a addObjectToBothSideOfRelationship how does EOF know which relationship is the inverse relationship?
In Core Data this is explicitly set but not in EOF.

EOF is smart enough to look in the model and see that there is a relationship on the destination that, in turn, has a destination of the original object, therefore it must be the inverse.

Take the hypothetical case where there would be two relations back to the source from the destination, what would happen then?

Dave

Paulo F. Andrade

References:
	>A few basic questions about EOF (From: Paulo Filipe Andrade <email@hidden>)
	>Re: A few basic questions about EOF (From: David Avendasora <email@hidden>)