-
Notifications
You must be signed in to change notification settings - Fork 254
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
"Deep" Object Graphs get serialized as "{}" #71
Comments
@jbattermann You need to tell Jil to include inherited members. You can do this by either passing With
By default inherited fields aren't included as, at least for the roles Jil was envisioned for in my projects, it's often unwanted behavior. It's there if you need it though. |
Ah I see - thanks for the clarification. Good stuff. Thanks Kevin! |
@kevin-montrose one question regarding the same 'area': Options.IncludeInherited did in fact add the inherited properties in the serialized Json, but it doesn't work the other way around - if I pass in the same Options to the .Deserialize(..) call, the nested property is returned as 'null'. I've read over the documentation but saw nothing that would indicate why it's leaving out that property (but it does mention the originally overlooked Optiones.IncludeInherited, sorry for asking what was clearly indicated :-/). I've updated the gist and marked the line (see https://gist.github.com/jbattermann/9589865db33742e2280b#file-deepobjectgraphtests-cs-L45), maybe you can give me a push in the right direction. Thanks! |
@jbattermann that may be an actual bug, I don't have time to dig in right this second but I'll try and set aside some time this week for it. |
Thanks @kevin-montrose , highly appreciated! Let me know if you need any more samples/input or whatsoever. |
Removed BindingFlags.DeclaredOnly to find fields/properties. I don't see the need to make this an option, because if the fields exist in both the json and the object then they will be deserilized; otherwise they won't.
Fix is here |
#76 merged in |
Thanks Kevin & @manofstick ! |
Removed BindingFlags.DeclaredOnly to find fields/properties. I don't see the need to make this an option, because if the fields exist in both the json and the object then they will be deserilized; otherwise they won't.
I am not entirely sure whether this is a bug in Jil or me expecting a feature that is not there, but after exchaning Json.Net with Jil in a project, I got unit test errors stating that the returning Json was empty (as in "{}") but actual serialized objects were expected.
I've created a Gist to reproduce this with Jil 2.1.0 but basically what's going on there is an attempt to serialize an object that has 2 inheritance levels ('UserCredentialsUpdateResponse' > 'UserResponse' > 'Response') and that 'UserResponse' class has a '.User' property whose type also has one inheritance level (the types are simplified but those are levels of nestings actually going on).
When serializing an instance of 'UserCredentialsUpdateResponse' I'd expect it to serialize the graph, but I get '{}' back from the Jil.JSON.Serialize(..) call.. which is odd.
The sample Test / repro is here: https://gist.github.com/jbattermann/9589865db33742e2280b
Is my object graph simply unsupported or 'should' this work?
The text was updated successfully, but these errors were encountered: