I agree with this completely. WO will load ALL the to-many-related
objects from the database when you try to set the inverse to-one
relationship on a new object, which when there are thousands of
related objects, this can cause a huge delay, especially in Java
Client applications where the client then requests all the objects be
sent to the client from the server. Ouch.
I have always just not modeled the inverse, unless I discovered a
compelling reason to _expect_ all the related objects to be in
memory. I didn't realize that if the relationship isn't marked as a
class attribute that it wouldn't fetch them. That is interesting and
would make the model much more intuitive.
Using a FetchSpec to go get the to-many-related objects manually has
worked well for me as it only incurs the often substantial overhead
if and when I explicitly ask it to.
Dave
On Feb 6, 2008, at 11:32 AM, Robert Walker wrote:
At least if using standard EOF classes, having the reverse to-many
relationship as a class properly on the EO can cause very major
performance problems because the to-many fault can get fired when
you don't expect it. This can happen even if you never directly
access the to-many relationship. I've had nightmares about this
very problem in the past. I now consider the implication of adding
the to-many side as a class property. If I expect it could return
more than a few hundred objects then I don't use it. I still model
the to-many side, I just don't set it as a class property. It's
entirely possible that Project WOnder classes take care of this
problem. I just wanted to make sure you were aware of it.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
