-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
[JAVA] discriminator.mapping is not supported (in generated model) #417
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
Comments
According to you having the Where is the information about the field name ( |
@jmini no, it's not sufficient @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "petType", visible = true ) I didn't notice it because it's generated correctly. |
One more thing, petType property is also generated in the Pet model. @JsonProperty("petType")
private String petType = null; This way wrong json is produced: {"petType":"Dog","name":null,"petType":null,"packSize":10} |
@jmini I can fix this and change jackson annotations to @JsonSubTypes({
@JsonSubTypes.Type(value = Cat.class, name = "catttt"),
@JsonSubTypes.Type(value = Dog.class, name = "dogggg"),
}) Also, I can remove property identifying type (in my example is 'petType') from the pojo. What do you think? |
Yes, I have started to work on it: This is work in progress, but my Idea was to edit the templates so that the cases described here are covered. |
So, this method (modelInheritanceSupportInGson) won't be needed? Am I right? And, |
I know it's WIP, but a small note: |
Thank you a lot for this feedback.
Yes this was my idea. And an other template change is needed to remove the creation of the discriminator as field:
(did not investigate yet)
Nice catch, I did not analyze who was computing the "children" map.
Nice catch! Do you want to take over the PR? I have not that much time right now. There is also a small spec |
I will try, but I'm not very comfortable with the code right now (I mean, not very familiar with). Will get back if I have questions. |
This is always the case. I just fix stuff in for the Java generators and I help at model level (the codegen classes that are exposed in the templates). Then I consider that people with knowledge of other languages needs to consume the elements in their models. I can help you if you need to know something, but from the feedback you gave me on my WIP commit, I think you know enough to create a great PR. |
I almost finished. Will submit PR soon (I had only to change templates and do some minor stuff). It is a little bit hard to do this. I will write some thoughts after I submit PR |
Sure feel free to do stuff in multiple small steps... |
Regarding not including discriminator field from model (petType from this issue)
I tried to implement 2.2, but it's not that easy: I needed to change hasMore, hasVars and possibly other auxiliary fields from What do you think about this? |
I will come back to you with the problem I see with the discriminator in the properties. I am no longer sure what we need. I will give you an example that is not working at all (using In the mean time, I think it is important to document changes like this in the migration guide, I have opened #587 for that. |
The fix for this may also be needed for Java Spring target? |
According to the status of the PR, I assume that this has been fixed since Because I'm still facing the same issue when generating from swagger. Although one difference is that my I have:
And in turn the Actual:
Expected:
|
This is also biting me with the following spec and 4.2.2:
this gives
and the discriminator is set to the class's name instead of the specified mapping. There also isn't any |
Note that if you upgrade to an OpenAPI specification instead of swagger 2.0 and use f.e. the |
Might be mistaken - this should be on OpenApi 3.0. Silly me. The |
openapi.generator does not play well with discriminator(s) from the openapi spec. related issues: OpenAPITools/openapi-generator#4559 OpenAPITools/openapi-generator#417 the api_ldap_identity_providers.go is a copy/paste search and replace of api_identity_providers.go to return LdapProviders instead of sub stub IdentityProvider we need to do the same for the identity provider types. Signed-off-by: Daniel Nilsson <[email protected]>
Just looking at some examples in this conversation that worked (e.g @ivarreukers example), do we really need a self reference from the child to the parent (thus creating that dependency between discriminator and its implementation classes) According to the example of discriminator in inheritance and polymorphism, the following should work (without cyclic reference between child back to parent)
This generated the right
but the child does not have the extension to the parent
|
Thats because of #8495 |
Description
spec: https://swagger.io/docs/specification/data-models/inheritance-and-polymorphism/
mapping can be specified in discriminator:
Currently it's not taken in account when generating model (it's not for Java, may be for every other language too)
openapi-generator version
3.1.0-SNAPSHOT
OpenAPI declaration file content or url
Command line used for generation
java -jar ... generate -i api.yaml -g java --library resttemplate
Steps to reproduce
Generate model
Here is what's generated in Pet.java:
Related issues/PRs
Related to #197
Suggest a fix/enhancement
Should generate model like this:
The text was updated successfully, but these errors were encountered: