please see replies inline. On Fri, May 29, 2020 at 1:14 PM Jarek Potiuk <jarek.pot...@polidea.com> wrote: > This is fine if "additionalProperties" are used. But when you go with the > fully freeform - > the message will be the same as I understand "Model ,,, not generated since > it's a free-form object >
Then it becomes an implementation issue of openapi-generator which can be fixed by updating templates as long as the target language supports this pattern. > > > * REST client for JIRA (not sure which language) : > > > > > https://community.developer.atlassian.com/t/jira-rest-client-generation-fails-swagger-open-api-generator/36398 > > > Same here - the scheme for the "object" field is defined but the generator > treats it as it is not defined: > > The problem here is that in the FieldValueClause object, the operator > > property has an enum list with a bunch of l > > ogical operators (i.e. =, !=, >, <, etc.) – and they’re typed as string. > > However, you’ll see that null value in the list > > – which, by the OpenAPI spec 4 is completely acceptable… but the > > openapi-generator doesn’t seem to like it. > > > So the generator thinks that the field is FreeForm because it has complex > definition. And it falls back to default > mode when there is no specification for the object field. This is a bug with openapi-generator itself with regards to enum type support, which has nothing to do with supporting generic object. It just happened to fallback to generic object in this case, which was not implemented. Again, if a pattern can be supported by a language, one can just update the template in openapi-generator to support it. Whether or not we want to make improving openapi-generator a blocker to getting Airflow API v1 out is a different question ;) > > On top of this, the example used in this blog post is different > > because it actually has a strict schema for each value item, which is > > id in string. In our case, the value is a truly free-formed nested > > JSON object. > > > > Not really. The first approach to schema is stricter but then (as it is not > possibe to use > arrays) the author falls back to generic :object (same as we have). > The author recommended a workaround without having to use generic object because each value has a strict schema. This is not the case for conf because it's a truly free formed json object. So his argument can only be used to prove using object should be avoided when value has a fixed schema, which is not the case for conf. > I believe the openpi generator by design does not work with fully > freeform objects because it can't in many cases. > > The issues mentioned are falling back to the behaviour where > no schema is defined even if the schema is defined, > I have contributed to openapi-generator in the past, so I am fairly familiar with the code base. From what I have seen, there is nothing magical about it. It's just mapping openapi spec to templates for different languages. If a pattern can be supported by the language itself, it should be easy to update the template to output that code. So far all the openapi-generator issues I have seen are all either caused by bugs or lack of features that can be fixed with proper implementation, not a design issue of the generator itself. If we can find specific examples in openapi generator that cannot be addressed due to design limitation of the tooling itself, then that would be a great way to settle down on the decision to move forward.
