Re: Error with proxy objects and to-many relationships with Core Data
Re: Error with proxy objects and to-many relationships with Core Data
- Subject: Re: Error with proxy objects and to-many relationships with Core Data
- From: Greg Herlihy <email@hidden>
- Date: Sun, 26 Feb 2006 20:21:32 -0800
- Thread-topic: Error with proxy objects and to-many relationships with Core Data
The program is attempting to make the NSArrayController's own proxy object
the contents of the to-many relationship. Data added to the object graph
cannot be proxies for the data to be added but has to be the modeled data
itself. Another way to look at the problem is if the proxies could replace
the data they are supposed to be proxying, they would would no longer be
proxies of data but would have become the data itself.
The other problem this program is likely to run into is specifying a single
object for a to-many relationship. When specifying the contents of a to-many
relationship, the program should first place the object or objects into an
NSSet or request an NSMutableSet of the relationship's objects to manipulate
on its own.
But here's a way to make to-many relationships easier to manage - especially
when the program wants to add a single object to a relationship that already
has existing members. Instead of dealing with the to-many relationship, the
program can instead specify the content for the inverse, to-one relationship
on the object to be added (and there should be an inverse relationship in
most models). By setting up one-half of the relationship (the simple side of
the relationship), the program is spared the more complicated, multiple
object operation, and just lets Core Data deal with it.
Greg
On 2/26/06 7:35 PM, "Sean Willson" <email@hidden> wrote:
> I am working on an application that is having a problem when I'm trying to
> add an object to a to-many relationship. It appears to be when dealing with
> proxy objects returned from NSObjectController's. I am doing the following:
>
> - (void)showEditor:(WASomeObject *)inObject;
> {
> NSManagedObjectContext *context = [self managedObjectContext];
>
> if (nil == inObject) {
>
> inObject = (WASomeObject *)[NSEntityDescription
> insertNewObjectForEntityForName:@"SomeObject"
> inManagedObjectContext:context];
> [inObject setFooBar:[fooBarController selection]];
> }
> // ... other code ...
> }
>
> The fooBarController var is an IBOutlet that is wired up to an
> NSObjectController that always contains the currently selected object from a
> table. That works fine as I have other text fields that are hooked up to
> it's variables (like "name") that change when it changes.
>
> In my code data data model I have the FooBar object has a to-many
> relationship to the SomeObject which has the inverse to-one relationship
> also defined (i've tried redefining in many ways, nada).
>
> Now when I call that setFooBar method, at the point it calls
> setPrimitiveValue method I get the following error:
>
> 2006-02-26 21:16:53.472 MyApplication[2254] setFooBar -
> <NSKVONotifying__NSControllerObjectProxy: 0x355d90>
> 2006-02-26 21:16:53.473 MyApplication[2254] *** -[_NSControllerObjectProxy
> _isMaintainingInverse]: selector not recognized [self = 0x355d90]
> 2006-02-26 21:16:53.473 MyApplication[2254] *** -[_NSControllerObjectProxy
> _isMaintainingInverse]: selector not recognized [self = 0x355d90]
>
> When I write some code that directly instantiates a SomeObject using the
> insertNewObjectForEntityForName method and then also instantiate a FooBar
> object the same way and call the setFooBar all is fine.
>
> In case it matters, this method above is in a custom NSArrayController that
> has the right managedObjectContext set, I've tested that out a few ways as
> well. I've also tried using the [fooBarController content] method instead of
> the selection one when calling setFooBar. I have added a print method into
> the addSomeObjectsObject method on the to-many side, it never gets called.
>
> Does anyone have any ideas on how to diagnose this problem? In general there
> aren't that many good large scale core data references out on the web right
> now and it's quite painful. I am working on a detail application that is
> quite dependent on Core Data and find the documentation to be quite sparse.
> There are samples from different sources but
>
> Thanks for the help.
>
> Sean
> _______________________________________________
> 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