Skip model generation if it's a top-level map or array

[wing328]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

Skip model generation if it's a top-level "additionalProperties' (an alias to "additionalProperties")

Closes #391

cc @OpenAPITools/generator-core-team

[etherealjoy]

@wing328
It worked very well apparently.
This issue #922 is solved in this case
But it generated the inline ref to array model as AmfUpdateEventSubscriptionItem_inner and the following log is generated

[main] INFO o.o.codegen.DefaultGenerator - Model AmfUpdateEventSubscriptionItem not generated since it's an alias to array (without property) 

I think here is a matter of choice how we want to do for alias, if we use refname or inner

However it does not apply this behavior when the array/map alias is part of a model like here #1251/#1273

We can do this as a next steps.
Thanks a lot of the update.

[wing328]

@etherealjoy thanks for the review.

cc @OpenAPITools/generator-core-team

[etherealjoy]

Fixes #397/#922

[etherealjoy]

I have a regression here with #391 :(
go client does not build. go server does build.

EDIT:
I think mainly client generators are affected in both map and array aliases.

[wing328]

@etherealjoy I'll take a look tomorrow to see if I can hunt down the bugs

[etherealjoy]

@wing328
Also solves #397 #922
Still to be solved for non top aliases like #1251/#1273

[wing328]

I pushed another fix and got the following (different) code snippet for fromJson method when using the spec in #1273

void UeContext::fromJson(const nlohmann::json& val) { { m_Groups.clear(); if(val.find("groups") != val.end()) { for( auto& item : val["groups"] ) { m_Groups.push_back(item); } } } }

Please give it another try when you've time.

[etherealjoy]

@wing328
This is nice, I compiled #1273 successfully.
Solves #1273, #397, #922, #391

#1251 need OAS3 support as well so not in this scope.

[eriktim]

Fixes #1465 as well!

[wing328]

If no further feedback on this PR, I'll merge this on coming Monday.

[CyrilleBenard]

I pushed another fix and got the following (different) code snippet for fromJson method when using the spec in #1273

void UeContext::fromJson(const nlohmann::json& val) { { m_Groups.clear(); if(val.find("groups") != val.end()) { for( auto& item : val["groups"] ) { m_Groups.push_back(item); } } } }

Please give it another try when you've time.

I still got this kind of wrong generated code with current master (3.3.4) :/

[etherealjoy]

@CyrilleBenard
This is correct

std::vector<std::string> m_Groups; m_Groups.clear(); if(val.find("groups") != val.end()) { for( auto& item : val["groups"] ) { m_Groups.push_back(item); } }

 UeContext: type: object properties: groups: type: array items: $ref: '#/components/schemas/GroupId' GroupId: type: string

[CyrilleBenard]

Oh sorry I omitted m_Groups was a string. I got the same kind of issue when m_Groups is a type defined by a model class. I'm going to reproduce the issue in a small context usage and will open another bug issue.

[etherealjoy]

@CyrilleBenard
OK, please do.
Could just then be specific to the generator.