Re: Question about Core Data Inverse Relationships

On Sep 20, 2009, at 16:58, Bennett Smith wrote:

> Well, I'm not sure plain logic would tell me this is impossible.  
> Clearly it is impossible using just a single relationship, but in  
> many OO programs I have written there are objects that will live in  
> different collections based on their current application state. This  
> is precisely what the Attribute is in my problem. When a new  
> Attribute begins life the process would be as follows in a pure OO  
> implementation sense:
>
> 1. Locate any existing Attribute in the "currentAttributes"  
> collection that matches the attribute name.
> 2. If an object was found in step 1 move it to the "oldAttributes"  
> collection so we can keep around knowledge that is once existed.
> 3. Insert the new Attribute into the "currentAttributes" collection  
> and set the dateRecorded date to "now".
>
> This seems completely reasonable in an application, but clearly  
> there is more work to do before it can be translated into something  
> Core Data is happy with. That is why I posted the question.

Reasonable? I really don't think so. This is a complex procedure, and  
I even had to read it twice to understand what you are saying. You  
sure should not expect CD to do that stuff for you automatically. I  
think that should be perfectly clear and logical. CD is not AI, it  
does not interpret any "old" or "current", let alone what that may  
mean in English. A relationship is just that: it's a relationship, and  
it's set or not. All CD can do is keep track of a PAIR of inverse  
relationships and set one when you set the other. If you want  
something like you say, you'll have to do it yourself in code.

> Since Attribute contains the same attributes whether it is in  
> "currentAttributes" or "oldAttributes" it seems kind of silly to  
> maintain two relationships on every Attribute. If one choose to go  
> this route how would one represent that either the relationship for  
> "currentAttributesUser" or "oldAttributesUser" must always be nil  
> since an attribute cannot be in both relationships at the same time?

When you remove an entity from a relationship, CD can remove it  
automatically from the reverse relationship.

However what you want is apparently something very different: you want  
to remove an item from currentAttributes and add it to oldAttributes,  
based on some OTHER item being added to currentAttributes. That's  
something CD cannot do for you. That has nothing to do with inverse  
relationships, because currentAttributes and oldAttributes are in no  
way inverse. There's no relationship CD can know of between these  
relationships.

> I was looking at the possibility of using a Core Data abstract  
> entity as a "base class" for two different attribute types. I would  
> put all of the shared attributes in the abstract entity and only  
> have the relationships in the derived entities. I tried finding more  
> information in the Core Data book by Marcus Zarra, but nothing  
> immediately jumped out at me.

So what's the question here? You can just do that in the entity  
editor, just set the parent entity in the subentities and add the non- 
shared relationships and attributes.

Christiaan

>
> Could someone familiar with the use of Abstract Entities in Core  
> Data please comment on whether this approach is worth considering?
>
> Many thanks.
>
> -- Bennett
>
> One possibility
> On Sep 20, 2009, at 3:07 AM, Christiaan Hofman wrote:
>
>>
>> On Sep 20, 2009, at 6:18, Bennett Smith wrote:
>>
>>> Well, I tried to attach the diagram, but guess the mailing list  
>>> strips it out.  The jist of the diagram was that I have the  
>>> following entities:
>>>
>>> User
>>> name
>>> currentAttributes (to-many relationship with Attribute)
>>> oldAttributes (to-many relationship with Attribute)
>>>
>>> Attribute
>>> dateRecorded
>>> name
>>> value
>>> user (relationship with User)
>>>
>>> The problem I'm having is with setting up the inverse relationship  
>>> in the Attribute entity. I would to specify an inverse  
>>> relationship for both currentAttributes and oldAttributes, but  
>>> can't see how to do this.
>>>
>>> Many thanks, and sorry for the confusion about posting the diagram.
>>>
>>> Cheers
>>>
>>> -- Bennett
>>
>> Plain logic tells you this is impossible. An attribute can be both  
>> an oldAttribute and a currentAttribute,so which user should be set  
>> in the user property? You should not have to ask this. So you'll  
>> have to change your model, and add another user relationship to use  
>> as the inverse of oldAttributes.
>>
>> Christiaan
>>
>>>
>>> On Sep 19, 2009, at 9:14 PM, Bennett Smith wrote:
>>>
>>>> Forgot to attach the diagram:
>>>>
>>>>
>>>>
>>>> On Sep 19, 2009, at 9:09 PM, Bennett Smith wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> I am stuck on a problem that I just can't figure out.  I am very  
>>>>> new to Core Data so it might just be that I am going about this  
>>>>> wrong. I want to setup a model for something like this:
>>>>>
>>>>>
>>>>> The currentAttributes and oldAttributes relationships in User  
>>>>> are configured as "to-many relationships." My problem is in  
>>>>> figuring out how to set an inverse relationship in the Attribute  
>>>>> class. It seems like I cannot have an inverse relationship that  
>>>>> points back to User for all Attribute entities in this case. (At  
>>>>> least I can't figure out how to do it in Xcode.)
>>>>>
>>>>> The purpose for this model is to allow me to track a set of  
>>>>> attributes associated with a user and to keep track of any  
>>>>> changes in the attribute values over time. A change is defined  
>>>>> as replacing the value associated with the attribute or deleting  
>>>>> an attribute. I am open to other suggestions on how to achieve  
>>>>> this goal using Core Data.
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Bennett
>>>>> _______________________________________________
>>>>> MacOSX-dev mailing list
>>>>> [email protected]
>>>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>>>
>>>> _______________________________________________
>>>> MacOSX-dev mailing list
>>>> [email protected]
>>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>>
>>> _______________________________________________
>>> MacOSX-dev mailing list
>>> [email protected]
>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>
>