entityPrimaryKeyInjectionBlock with AFNetworking 2.0

[iandundas]

Is this implemented? In the blog post describing the AF2.0 way of working (which I'm using), you state:

However, some features of MMRecord are not supported, such as pagination, MMRecord request options and custom response blocks. If any of these missing features seem important to you, please submit a pull request or open an issue and we will investigate supporting them in the future.

So I don't think you're mentioning primary key injection as being unimplemented, however that entire region of code in MMRecord never seems get called after setting a entityPrimaryKeyInjectionBlock on my entity.

Maybe I'm doing something wrong?

MMRecordOptions *options = [Transaction defaultOptions];

options.entityPrimaryKeyInjectionBlock = ^id(NSEntityDescription *entity,
        NSDictionary *dictionary,
        MMRecordProtoRecord *parentProtoRecord) {

    NSLog(@"Here is never reached :( ");

    return nil;
};

[Transaction setOptions:options];

just wondering if I'm mistaken. I'll dig in now too.

[iandundas]

OK if I add the following code to AFMMRecordResponseSerializer around line 123:

MMRecordResponse *recordResponse = [MMRecordResponse responseFromResponseObjectArray:responseArray
                                                                       initialEntity:initialEntity
                                                                             context:self.context];

// New code here:
Class subEntityClass = NSClassFromString([initialEntity managedObjectClassName]);
if ([subEntityClass respondsToSelector:@selector(currentOptions)]){
    MMRecordOptions *options = [subEntityClass currentOptions];
    recordResponse.entityPrimaryKeyInjectionBlock = options.entityPrimaryKeyInjectionBlock;
    recordResponse.recordPrePopulationBlock = options.recordPrePopulationBlock;
}

Then I can see the entityPrimaryKeyInjectionBlock block getting used, however it doesn't have the correct effect of updating (rather than inserting) entities.

In addition, another different entity for which I should be able to enforce primary key uniqueness simply by assigning MMRecordEntityPrimaryAttributeKey to one of it's fields, it isn't "upserting" records either, only inserting them. So maybe this functionality is broken for the AF2.0 route? Or maybe I'd doing it wrong 🌊

[cnstoll]

Hey Ian. Are you sure that there isn't a primary key configured on your Core Data model thats being found within the initial response object? Currently the block would not get called if your response object contains a primary key for a given record.

I'm over at CocoaConf today but I'll try to take a look at this later this weekend. We shouldn't have to add anything to the response serializer to get this to work. Logic for the injection is all part of MMRecordResponse, which the serializer is simply using.

Maybe there is a use-case for the block here that we need to take into consideration? It was mainly intended for providing a key when a dictionary representing an object did not include one. It wasn't intended to be used for overriding what the normal population process would normally assign as the primary key.

Thanks,

• Conrad

[iandundas]

Hi Conrad,

I misunderstood how it worked: I didn't realise the key actually had to be created first in CoreData and then could be populated later using the block - I thought the block was magic. Anyway, after some experimenting I got it working, and I'm not sure the issue exists now. I'll close.

[cnstoll]

Cheers!

[jonbrooks]

I was wondering if one of you could clarify what the solution looks like. I find the same problem as Ian describes in the original post - that there's no way to set the entityPrimaryKeyInjectionBlock on the response object - without making changes to AFMMRecordResponseSerializer. If request options are not yet supported with AFNetworking 2.0, how does one specify a entityPrimaryKeyInjectionBlock for a given entity?

[cnstoll]

Well, the solution is probably just to have an option on the response serializer to accept the injection block. The response serializer is a relatively new class, so that just wasn't added yet. I'll add this to the upcoming milestone and my todo list.

Thanks for commenting on this. I think that made the need here a bit clearer for me.

[jonbrooks]

Super - good to know I wasn't missing something obvious. Excellent framework, BTW!

[iandundas]

seconded ;)

[cnstoll]

Check out this PR and let me know if you think this would work for you. It allows you to set an MMRecordOptions object that gets used by the response serializer.

#73

[jonbrooks]

Yes, I'm confident this would work for my needs. In fact, when trying to find a way to get this to work, I even explored trying to override [MMRecord defaultOptions]. Looks like an improvement to me.

[cnstoll]

WooT! Awesome. Thanks :)

👍