> > > > From what I understand - that single choice prevents our customers to > > use auto-generation in many languages > > = reasons for that explained by Kamil). Here are few examples: > > > > * Typescript: > https://www.gitmemory.com/issue/OpenAPITools/openapi-generator/4119/540506783 > > This looks like a implementation error of openapi-generator, not an > issue with free form object pattern itself. As mentioned in the > comment, it should be implemented the same way the go client generator > is, which is to model it as a map with string as key and generic > object as value. >
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 > > > * Java: https://github.com/OpenAPITools/openapi-generator/issues/2037 > > This looks like another openapi-generator implementation issue that's > already fixed? > It looks like - but it's not when you look deeper. The problem in the issue was that the property scheme was defined for all properties but it was treated as if it is not defined. So it's fixed if you define your schema - but we cannot t... > > > * 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. > > > Based on pasted logs in that thread, it looks like another > openapi-generator implementation error to me. > > > * GO: > https://medium.com/real-apis/free-form-objects-with-array-values-72e85c044e4a > > Based on the generated go client code that Kamil linked above, it's > already using the right type for conf [3], which is > "map[string]interface{}" as mentioned in the blog post. > Not really. the author started with the definition that he tried to use (with additionalProperties) but since he could not use it because his object type is not well defined and supporting arrays - he fall back to generic: object (same as we have) and he lost all the type information and got the typing errors... > 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). > Again, I am not familiar with Java, but I can confirm that you won't > have to do this for languages like Go, Rust and C/C++ :) I have feel > that if it works in Rust, then it should work for Java as well since > Java has a more dynamic runtime. > I would love to see an example of Java client that works in case of : a) conf : { "x": 34 } b) conf: { "a": [1, 2, 3] } c) conf: { "Z": [1,2], "W": "a" } Without having to recompile the code between a/b/c and adding a new set of conf parameters for a new DAG. Please. I'd love to see the complexity of the code in Java. I am not telling it is impossible, but I am telling that it will simply not work out-of-the box. > > So the question to us is whether we want to spend time improving > openapi-generator down the road, if not, then we should just use > string type instead of object to work around all the potential > implementation issues. > 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, -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
