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

Reply via email to