Re: A few basic questions about EOF
Re: A few basic questions about EOF
- Subject: Re: A few basic questions about EOF
- From: Chuck Hill <email@hidden>
- Date: Tue, 24 Mar 2009 13:14:30 -0700
Hi Paulo,
On Mar 24, 2009, at 12:15 PM, Paulo Filipe Andrade wrote:
Hi!
Thanks for the comments.
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?).
There is less processing and object creation, so it will be a bit
faster. I would not be too concerned with this one way or the other.
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?
I'd be tempted to keep the compound PK and just make the minimal
change. I think this is 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.
There is no delete rule that will do this. I'd probably implement
this on Message:
public void removeFromUsers(User aUser) {
super.removeFromUsers(aUser);
if (users().count() == 0) {
editingContext().deleteObject(this);
}
}
You might find this problematic if the last user can be removed then
another one added. This opens up all sorts of interesting concurrency
problems.
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?
It looks for one that matches the join columns. I am not sure what
happens if you have two identical relationships, nor I am sure why you
would have two identical relationships.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden