-
Notifications
You must be signed in to change notification settings - Fork 306
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
Add handling of collections with polymorphic types #11
Comments
Inheritance is actually fully supported already. Just annotate the parent and child as |
sorry i described things unclear. I mean if the json provides type information, for example: @JsonObject
class Animal {
@JsonField
String name;
}
@JsonObject
class Cat extends Animal {
@JsonField
String coatColor;
}
@JsonObject
class Dog extends Animal {
@JsonField
String breed;
} The json could look like this: [
{
"type" : "dog",
"breed": "German shepherd"
},
{
"type" : "cat",
"coatColor": "black"
}
] So the parser should be able to distinguish the type from json. In my json parser you can do that like this: @JsonObject
class Animal {
@JsonField
String name;
@JsonFiled( subTypes = {
@JsonSubType( key = "dog", value = Dog.class),
@JsonSubType( key = "cat", value = Cat.class),
}
)
String type;
} The parser should be able to parse |
This is an interesting use case. I guess I haven't encountered an API that can spit out different types of data within the same array (even if they are all of the same superclass), but there's nothing in the JSON standard saying that can't happen. I'll have to think through what a good annotation schema would be and what the annotation processing would look like to be able to handle something like this. Off the top of my head, I can't think of a way to do this without a big performance penalty. PS - Just to keep the issue tracker clean and easy to read, could you change the title of this issue to something like "Add handling of collections with polymorphic types"? Right now it looks like you're requesting something that's already there. |
Is it possible to manually override this behaviour - e.g. with a TypeAdapter? For example adding a field when serializing that indicates which class each object maps to, and similarly creating the correct class when deserializing? |
Hi. I am also facing this issue and I've just made an example code which handles polymorphic object parsing/serialization. https://github.com/h6ah4i/logansquare_polymorphicparser |
@h6ah4i Thanks, how is it performance wise? |
@zoltish I have not measured the performance, but I think it is the optimal implementation. I'll compare the performance with another libraries :) |
I have a field that is sometimes a String and sometimes a JSON Object, ex: "schedule_type":{
"type":"Cycle",
"value":{
"cycle":"21+7"
}
}, "schedule_type":{
"type":"Items",
"value":"1,2,3"
} |
I have this case where the acted_upon_type determines how acted_upon will be, acted_upon could be Post,Comment, Answer,Question |
Just spent the entire day trying to pin this down, exactly the use case @sockeqwe describes. Is anyone aware of any alternative means of generating polymorphic types from a list of the common parent class? I guess I'll have to go back to gson :/ |
@AdityaAnand1 @lkraider i've solve this by using this: public class Response { |
any update on this? this could be handled by a typeconverter right? |
three years passed since this issue was opened and yet no solution to the problem |
Time to get on the moshi train @lhalegria 😄 |
As far as I have seen there is no support for inheritance. I have worked on a very similar project (annotation procession based json parser) with features like you implemented (you have more features though, but the basic features are the same). However, I have implemented Inheritance resolution similar like Jackson did. Since my annotation processor is in alpha and I consider your parser as more advanced, I consider to switch over to your parser and I would like to ask you if you would accept pull requests for inheritance or are you currently working on that? Or does your roadmap specifies inheritance for a much later version like 2.0.0?
If you are interested in we can specify together the annotations.
The text was updated successfully, but these errors were encountered: