Re: CoreDate: Inverse relationship... (follow up)
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