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.
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?
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.
Dave