Import of related objects works only from 2nd time onwards, gives EXC_BAD_ACCESS on 1st run to empty DB

[ghost]

When I am importing a json structure like this, with User entities who own many Album entities (user.albums relation with inverse relation album.user)

{
    "users": [
        {
        "userno": 60905,
        "last_sign_in_at": "2012-08-09T04:59:37Z",
        "albums": [
            {
            "artist": "Franz Ferdinand",
            "albumID": 14647,
            "userID": 10205
            },
         ],
        "userID": 10205,
        "username": "John Doe"
        }
    ]
}

On the first run, to a completely empty store, I always get an EXC_BAD_ACCESS error when the the context is being saved (-NSManagedObjectContext(MagicalSaves) MR_saveWithErrorCallback: -> Saving <NSManagedObjectContext: 0x6b4eb50>: Context). The user has been saved, but no album has been saved.

Yet, when I run the exact same import a second time, with the user present in the storage, the album will get saved. When the album owner is present in the DB, the relationship objects get imported fine with no problems, but when I try to import the user and the albums in the same run, I get the error.

Could the structure of the above json dump be the reason? The api server outputs the relationship objects (albums) in the middle of the user attributes, especially before the crucial "userID" key attribute. Supposing MR reads in the attributes in the same order, then it has no userID at the time it is processing the album relation.

If that's the case, it would probably be best to somehow coax the API server to put the relationship attributes behind the "foreign key" attribute? Or what would be the best practice to fix this? Thank you!

[blackgold9]

Probably a nested context bug. Working on it

[blackgold9]

Please try out the iOS5NestedContextFix branch for a fix here. It's experimental code that may take care of the problem.

[Vortec4800]

Thought I would comment, I'm having a similar BAD_ACCESS crash with nested contexts (not sure if it's the same as in this issue or not) but the NestedContextFix branch worked perfectly. So far so good!

Running on iOS 6 GM.

[andyfitter]

Is there any news RE the NestedContentFix branch and the problems with IOS < 6.0? Seems fine on 6.0 but I'm seeing the same crashes as everybody else on lower versions.

[blackgold9]

Not yet :(. Hope to have something soon On Sep 17, 2012, at 2:24 PM, andyfitter notifications@github.com wrote:

Is there any news RE the NestedContentFix branch and the problems with IOS < 6.0? Seems fine on 6.0 but I'm seeing the same crashes as everybody else on lower versions.

— Reply to this email directly or view it on GitHub.

[blackgold9]

Should be fixed now

[tobiasbayer]

I checked out iOS5NestedContextFix but it does not compile: "MagicalRecordPersistenceStrategy.h not found"

[blackgold9]

I made changes to the master branch that i hope fixed the problem. Have you tried the latest from there? If so, can you send me a project that reproduces the problem? I'd love to get to the bottom of this On Oct 14, 2012, at 3:55 AM, Tobias Bayer notifications@github.com wrote:

I checked out iOS5NestedContextFix but it does not compile: "MagicalRecordPersistenceStrategy.h not found"

— Reply to this email directly or view it on GitHub.

[tobiasbayer]

I tried the latest master code and the problem persists. I cannot send the complete project but basically I do this:

NSManagedObjectContext *context = [NSManagedObjectContext contextForCurrentThread];
Person *person = [Person createInContext:context];
person.name = name;
person.date = [NSDate date];

[context save];

And I get an EXC_BAD_ACCESS on obj_msg_send.

I just tried to reproduce the error on another computer (both with Xcode 4.5) and it is not occuring there.

But the context does not seem to be saved anyway. Because fetching the saved entity afterwards returns nil.

[blackgold9]

What thread are you doing it on? I really recommend doing things either in the mainContext or in a [MagicalRecord saveInBackground:] block where possible. I'd like to see a more complete example to help pin down exactly what's going wrong. On Oct 14, 2012, at 10:09 AM, Tobias Bayer notifications@github.com wrote:

I tried the latest master code and the problem persists. I cannot send the complete project but basically I do this:

NSManagedObjectContext context = [NSManagedObjectContext contextForCurrentThread]; Unfollower unfollower = [Unfollower createInContext:context]; unfollower.twitterId = twitterId; unfollower.unfollowedOn = [NSDate date];

[context save]; And I get an EXC_BAD_ACCESS on obj_msg_send.

I just tried to reproduce the error on another computer (both with Xcode 4.5) and it is not occuring there.

But the context does not seem to be saved anyway. Because fetching the saved entity afterwards returns nil.

— Reply to this email directly or view it on GitHub.

[casademora]

It has been recommended that we look at modifying the contextForCurrentThread method on NSManagedObjectContext. With GCD and queues, this may not return the correct object. This may or may not be the cause of the issue, but could be related. Either way, it's worth looking into as well..

On Oct 14, 2012, at 11:15 AM, Stephen Vanterpool notifications@github.com wrote:

What thread are you doing it on? I really recommend doing things either in the mainContext or in a [MagicalRecord saveInBackground:] block where possible. I'd like to see a more complete example to help pin down exactly what's going wrong. On Oct 14, 2012, at 10:09 AM, Tobias Bayer notifications@github.com wrote:

I tried the latest master code and the problem persists. I cannot send the complete project but basically I do this:

NSManagedObjectContext context = [NSManagedObjectContext contextForCurrentThread]; Unfollower unfollower = [Unfollower createInContext:context]; unfollower.twitterId = twitterId; unfollower.unfollowedOn = [NSDate date];

[context save]; And I get an EXC_BAD_ACCESS on obj_msg_send.

I just tried to reproduce the error on another computer (both with Xcode 4.5) and it is not occuring there.

But the context does not seem to be saved anyway. Because fetching the saved entity afterwards returns nil.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[tobiasbayer]

I am doing it on a non-main thread. I'm sorry but I cannot provide more code of the particular project.

[blackgold9]

Understandable. The problem is that what you've given doesn't give the full threading context.

As a shot in the dark I'd recommend doing [MAgicalRecord saveInBackground:^(NSManagedObjectContext context){ Person person = [Person createInContext:context]; person.name = name; person.date = [NSDate date]; } completion:^{ // Trigger whatever else you were going to do. }];

That way the data access still happens off thread (but in the thread of the correct context), and you can continue after it's guaranteed everything has already saved.

Let me know if that approach works for you.

I'd still like some sort of a bigger picture on what you're doing because there are a few too many EXC_BAD_ACCESS issues popping up and we need to track it down.

[blackgold9]

try again. An optimization i made forgetting about cases where people call Cleanup might have screwed you over. Checked in a fix.

[Vortec4800]

Is the nested context fix branch still pertinent or should we be using the master branch now?

[blackgold9]

master should be latest stable. develop is where it's at for new stuff.

[Vortec4800]

I was on master but switched to the nested branch to get my project working. I'm just not sure if I should still be using that branch or if the master contains fixes for the stuff in the nested branch.

[blackgold9]

Master should have the relevant fixes. I need to delete the other nestedContextFix branch :/ On Oct 17, 2012, at 3:32 PM, Cory Imdieke notifications@github.com wrote:

I was on master but switched to the nested branch to get my project working. I'm just not sure if I should still be using that branch or if the master contains fixes for the stuff in the nested branch.

— Reply to this email directly or view it on GitHub.

[Vortec4800]

Ok thanks. I'll try master out again and if I run into any more issues with it I'll let you know.