Repository navigation
Non-KVC-compliant JSON keys don't deserialize as expected #418
Description
Hi,
I found bug while parsing json data. When we have special name of property in json (@description). Please look on my repo https://github.com/7tomek/JSONModelTests there are patch with test and lldb-console (print object).
Activity
billinghamj commentedon Dec 29, 2015
Hi @7tomek. Rather than creating a patch file, could you fork this repo and commit the changes directly to that? Makes it much easier for us to work with your changes.
billinghamj commentedon Dec 30, 2015
Thanks for that. Okay, so basically you've stumbled upon a feature of KVC in Obj-C.
See: https://stackoverflow.com/a/20453438
@at the start of a dictionary key when callingkeyPathmethods (as JSONModel does) has special meaning. This functionality allows JSONModel to support patterns like this:https://github.com/icanzilb/JSONModel/blob/master/JSONModelDemoTests/UnitTests/TestModels/ExtremeNestingModel.m#L17
As such, we can't remove or change this functionality. We might be able to escape or handle specifically the
@operators though.billinghamj commentedon Dec 30, 2015
Looks like the operators cannot be escaped. As such, we will not be able to resolve this without removing the
keyPathfeature.Unless you have any other suggestions, I suspect we simply won't be able to fix this one I'm afraid...
[-]Parse special property @description.[/-][+]Non-KVO-compliant JSON keys don't deserialize as expected[/+][-]Non-KVO-compliant JSON keys don't deserialize as expected[/-][+]Non-KVC-compliant JSON keys don't deserialize as expected[/+]jkmathew commentedon Dec 31, 2015
This is not for all special characters(I believe) but surely for @. More precisely keys starting with @.
My suggestion is to do something like send the dictionary and key to the Model class itself and it can pick the value it and with
objectForKey:method instead ofvalueForKeyPath:@billinghamj your thoughts?
billinghamj commentedon Dec 31, 2015
Yes, it is just keys starting with
@which are be the problem.One possible option would be allowing models to opt-out of the
valueForKeyPath:methods in favor ofobjectForKey:, losing the key path functionality.It seems a little complex to delegate the entire property retrieval code to the model.
billinghamj commentedon Sep 11, 2016
I'm inclined to say that this should be resolved in a JSONModel v2 which allows for more explicit configuration via the implementation file.