On May 30, 2008, at 5:19 PM, Mike Schrag wrote:
So, my memory is still not 100% clear on this one but I think
we're honing in on why I don't flatten....
If the relationship is not flattened then I have the option of not
using addObjectToBothSides if I know
I am doing an insert and then discarding the EO (i.e. I don't care
about keeping my object graph
consistent right now). It means I can avoid faulting in a whole
slew of stuff when I know I don't need it.
This seems right to me, yeah. That said, my standard approach is
that if the relationship is too big to fault, then I don't model it.
Same here.
It's VERY rare that I have the relationship modeled but don't want
the graph in sync.
We actually do it a lot. If you think about our system there are
some apps that spend 99% of their time
inserting data (think of when something is sold) and there are others
that spend 99% of their time reading
that same data (think of when something is invoiced). Those first
class of apps are not going to traverse
the object graph after the insert and need to be very fast. The
other class of apps will fetch and then
traverse the object graph and are not anywhere near as performance
sensitive.
This same topic came up in the discussions of automatic inverse
relationship updating in Wonder, actually.
You can probably guess how I feel about that ;-) I never model
inverse relationships until I need them
(and even then I sometimes don't)
Alan
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/award%
40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
