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.