Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trying to understand weird behaviour: Unexpected type while converting value for JsonSerialization #279

Closed
jfgates opened this issue Apr 10, 2018 · 11 comments

Comments

@jfgates
Copy link

jfgates commented Apr 10, 2018

Hi,

Really love your toolkits... Thanks for your work on these!

I am having the same issue as the previous guy with JSON Serialization. ( peterdk opened this issue on Aug 19, 2017 )

I placed a breakpoint on:

        evPrint(.InvalidType, "ERROR: Unexpected type while converting value for JsonSerialization: \(value)")
        return "\(value)" as AnyObject

and discovered that it was occurring in my test cases on :

XCTAssertNil ( UserInfo.userinfo ), where UserInfo is an CKDataObject for EVCloudKit

and
XCTAssertNotNil ( UserInfo.userinfo )

but is fine for
XCTAssert ( UserInfo.userinfo != nil ) and XCTAssert ( UserInfo.userinfo == nil )

Go figure.... I don't need a fix for these as I have a workaround. But thought you'd like to know.

Let me know if you need more info.

Joseph Gates
fgates@me.com

@evermeer
Copy link
Owner

Hi, Could you tell me what type the UserInfo.userinfo field is? Is it an other UserInfo object. Cloudkit cannot handle sub objects very well. It could be that se (de)serialization is not going right for this. I think that it could be that the field is set with a property of a type that's not equal to the type it should be. For instance a dictionary was assigned to the property instead of an object. But then your asserts are still strange.

@jfgates
Copy link
Author

jfgates commented Apr 11, 2018 via email

@evermeer
Copy link
Owner

Could you tell me what version of EVReflection that you are using? The current version is 5.6.0 It has an extension for CKRecordID that implement a custom reflection that was added in version 5.5.0. I hope that's the reason why the CKRecordID serialization fails. I also have seen that big data dump before. I thought I also fixed that in that 5.5.0 version. It had something to do with the CKRecord system fields that you don't want in your json but which are part of the CKDataObject object

@jfgates
Copy link
Author

jfgates commented Apr 12, 2018 via email

@jfgates
Copy link
Author

jfgates commented Apr 13, 2018 via email

@evermeer
Copy link
Owner

Thanks, I will create a EVCloudKit issue for this. I'm not sure why I used a semi back then instead of letting it over to the user in a async callback...

@evermeer
Copy link
Owner

Issue is created: evermeer/EVCloudKitDao#101

@jfgates
Copy link
Author

jfgates commented Apr 16, 2019 via email

@evermeer
Copy link
Owner

@jfgates It's right, there are a lot of code change needed for Swift 5.0 I tried it some time ago but then it costed too much time to fix. I will try again later this week.

@evermeer
Copy link
Owner

@jfgates I just started over and noticed the auto conversion caused a lot of errors. After manually doing the conversion from scratch the problems where quickly solved. The Swift 5.0 version is now pushed to GitHub and Cocoapods as version 3.6.1

@jfgates
Copy link
Author

jfgates commented Apr 17, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants