• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CoreDate: Inverse relationship... (follow up)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreDate: Inverse relationship... (follow up)


  • Subject: Re: CoreDate: Inverse relationship... (follow up)
  • From: Philip Dow <email@hidden>
  • Date: Sat, 30 Sep 2006 21:49:15 +0200

Ok, the problem has been solved but I certainly did not solve it myself. After some serious searching, I came across this post from May 2005:

http://lists.apple.com/archives/Cocoa-dev/2005/May/msg02827.html

I believe Jim was having the same problem I'm having, although I can't confirm it because his example project is no longer available. I am in fact using an abstract Reference entity here, with a sub entity called FileReference. I had tried collapsing the capabilities of the FileReference entity into the Reference and concreting that entity, but the problem persisted.

In a follow up to the May post, a certain John asks, "if you create files for the class, so that you have actual add and delete methods for the set items (instead of mutableSetValueForKey:) does this make a difference?" This is what I did. I had CoreData generate the class files for my Entry and Reference entities, and I added my own previously written custom methods to them.

So now, when mutableSetValueForKey is called to add a Reference to the Entry's "references" relationship, it would seem that the the generated addReferenceObject: method is called instead of whatever the CoreData framework had been supplying. Done this way, the inverse relationship is no longer lost, which I assume was the reason a NSCFNumber was returned when that inverse value was requested.

mmalc, you commented on Jim's post back in 2005. Is this still a known bug?

-Phil

On Sep 30, 2006, at 2:14 PM, Philip Dow wrote:

I'm stumped. In my model I have a Entry entity and a Reference entity. The Entry-Reference relationship is to-many, while the inverse is to-one. On the Entry side, the relationship's name is "references" and on the Reference side, the relationship's name is "entry". I've checked the setup a dozen times.

Both entities use their own NSManagedObject subclasses. I've checked this setup a number of times, and I'm certain I am following Core Data subclassing guidelines.

Because the Reference entity includes an "id" property which the entry uses to keep track of it, I've added a method to the Entry class which creates References:

- (Reference*) createReferenceForName:(NSString*)entityName {

Reference *newReference;
newReference = [NSEntityDescription insertNewObjectForEntityForName:entityName
inManagedObjectContext:[self managedObjectContext]];

[newReference setValue:[self nextReferenceIDAndIncrement] forKey:@"id"];

NSMutableSet *allReferences = [self mutableSetValueForKey:@"assets"];
[allReferences addObject:newReference];

return newReference;
}


The nextReferenceIDAndIncrement method looks like this:

- (NSNumber*) nextReferenceIDAndIncrement {

double nextIDdouble = [[self valueForKey:@"lastReferenceID"] doubleValue];
NSNumber *nextID = [NSNumber numberWithDouble:++nextIDdouble];
[self setValue:nextID forKey:@"lastReferenceID"];
return nextID;
}



For entityName I'm passing in the string "Reference." Everything seems to work. I can set properties on the Reference, display it in an NSTableView using bindings, etc.


However, there are parts of the code which access the Entry when the Reference has been supplied. Every time this code is called, the valueForKey method returns an NSCFNumber instead of the Entry with which the Reference is associated. The code is simple enough:

Entry *anEntry = [aReference valueForKey:@"entry"];

That anEntry variable is *always* a nNSCFNumber. Asking for any of attributes (title, icon, etc) returns the correct value. I'm completely stumped. The data model is correctly setup, I'm sure of it. The subclasses are proper, I'm sure as well. Why does valueForKey:@"entry" always return a number then when it is mapped to the Entry entity?

Recently, I did rename the Reference entity from "Resource," going through all the code and changing the necessary parts, as well as everything in the Nib files. I originally thought that could be related to the problem, but then I've completely re-written this part of the data model, even using different names for the entities and relationships. The problem remains the same. Short of trashing the data model file and rebuilding it from scratch, I don't know what to do.

Any direction would be appreciated.

-Phil

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: CoreDate: Inverse relationship... (follow up)
      • From: Jim Correia <email@hidden>
References: 
 >CoreDate: Inverse relationship returns NSCFNumber instead of entity (From: Philip Dow <email@hidden>)

  • Prev by Date: Re: Endless loop but only with release build
  • Next by Date: RE: Strange NSView redraw problem
  • Previous by thread: CoreDate: Inverse relationship returns NSCFNumber instead of entity
  • Next by thread: Re: CoreDate: Inverse relationship... (follow up)
  • Index(es):
    • Date
    • Thread