Hi Paul, I'm not 100% clear on how this is modeled.
1) Does the A.b() relationship propagate PKs? 2) Are you saying that the A.b().a() may be null? In other words, are you saying A.fetchAllAs().valueForKey(B_KEY) may not return an Array with the same objects that B.fetchAllBs(ec, B.A.isNotNull()) ? Dave On Jul 22, 2010, at 8:00 AM, Paul Hoadley wrote: > Hello, > > I know this topic comes up on the list from time to time, but I just need a > quick sanity check. > > I have two entities, A and B. For every A, there is a corresponding B. For > some subset of all Bs, each has a corresponding A. Currently I have modelled > this with a single relationship from A to B, so that's a mandatory to-one > relationship. (Alternatively, I could have modelled it with an optional > to-one relationship from B to A.) > > At different times, I need to traverse this relationship in both directions. > For any A, A.b() will give me the related B. But for the reverse direction, > say I have a B and I want its A (if it has one), I have a custom method B.a() > which does a fetch for the A such that A.b() is the B of interest. > Sometimes, though, I just want to know if there is an A for a particular B, > or whether it's null, and in this setting, the fetch is expensive. > > Here's where I need the sanity check: is there a way, given the constraints > above, to model an inverse to-one relationship from B to A such that it > appears as the inverse to EOF? That is, such that calling, say, > A.addObjectToBothSidesOfRelationshipWithKey(B, "b") does both A.setB(B) and > B.setA(A)? I'm assuming there's not, as I certainly can't beat the model > into doing it. I can work around it by doing the right thing at creation > time for every A, I just wanted to know if I was missing something where EOF > (or Wonder) would handle this automagically. > > > -- > Paul. > > http://logicsquad.net/ > > > _______________________________________________ > 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/webobjects%40avendasora.com > > This email sent to webobje...@avendasora.com > > _______________________________________________ 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 arch...@mail-archive.com