Skip to content
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

Impart intelligence to swagger importer to handle generic object types in incoming swagger. #942

Open
springwiz opened this issue Jul 9, 2020 · 5 comments
Labels
enhancement import Issues relating to importing other formats into Sysl. P0 Highest priority: important or urgent

Comments

@springwiz
Copy link
Contributor

springwiz commented Jul 9, 2020

Please do not post any internal, closed source snippets on this public issue tracker!

Current Sysl Version

0.136.0

Use-cases

Please describe the end goal you are trying to achieve that has led you to request this feature.
Explore the possibility of creating wrapper response types automatically in the generated sysl when the incoming swagger uses generic response object types without any schema. This will allow the codegen to work from the generated sysl without the need of manual modification in the swagger/sysl.

For instance the incoming swagger fragment:

  /rest?method=flickr.favorites.getContext:
    get:
      operationId: getFavoritesContextByID
      description: Returns next and previous favorites for a photo in a user's favorites
      tags:
        - Public
      parameters:
        - name: api_key
          in: query
          required: true
          type: string
        - name: photo_id
          in: query
          required: true
          type: string
          pattern: ^[0-9]+$
        - name: user_id
          in: query
          required: false
          type: string
          pattern: ^([0-9]+@N[0-9]+)|([0-9a-zA-Z-_]+)$
      responses:
        200:
          description: OK
          schema:
            type: object
            properties:
              count:
                type: object
                properties:
                  _content:
                    type: string
              prevphoto:
                $ref: '#/definitions/ContextPhoto'
              nextphoto:
                $ref: '#/definitions/ContextPhoto'
              stat:
                $ref: '#/definitions/Stat'

Generates:

    /rest?method=flickr%2Efavorites%2EgetContext:
        GET ?api_key=string&photo_id=string&user_id=string?:
            | Returns next and previous favorites for a photo in a user's
            | favorites
            return ok <: object

    !type object:
        count <: object_object_count?:
            @json_tag = "count"
        nextphoto <: ContextPhoto?:
            @json_tag = "nextphoto"
        prevphoto <: ContextPhoto?:
            @json_tag = "prevphoto"
        stat <: Stat?:
            @json_tag = "stat"

The importer ends up generating a lot of such generic object types which makes codegen impossible. Make the solution configurable on the command line.

Attempted Solutions

Manual modification of the incoming swagger/sysl looks as the only solution.

References

  • #2020
@anzdaddy anzdaddy changed the title Impart intelligence to swagger exporter to handle generic object types in incoming swagger. Impart intelligence to swagger importer to handle generic object types in incoming swagger. Jul 9, 2020
@orlade-anz orlade-anz added import Issues relating to importing other formats into Sysl. P0 Highest priority: important or urgent labels Jul 14, 2020
@ghost
Copy link

ghost commented Jul 23, 2020

What are you expecting the sysl to look like? is it just the nameing of the objects or something else?

@springwiz
Copy link
Contributor Author

springwiz commented Jul 23, 2020

Sysl should create wrapper types wherever possible. So lets say:

 /rest?method=flickr%2Efavorites%2EgetContext:
        GET ?api_key=string&photo_id=string&user_id=string?:
            | Returns next and previous favorites for a photo in a user's
            | favorites
            return ok <: PhotoResource

!type PhotoResource:
        count <: object_object_count?:
            @json_tag = "count"
        nextphoto <: ContextPhoto?:
            @json_tag = "nextphoto"
        prevphoto <: ContextPhoto?:
            @json_tag = "prevphoto"
        stat <: Stat?:
            @json_tag = "stat"

@ghost
Copy link

ghost commented Jul 23, 2020

so yes, its just the name you dont like. Where is it supposed to get the wrapper name from? It already tries to give it a sensible name.

@springwiz
Copy link
Contributor Author

So no not just the name, it has to use some kind of intelligent naming as the same scenario can repeat for multiple operations on an endpoint. The sysl ends up with multiple types named as "object" which results in invalid sysl.

@anzdaddy
Copy link
Member

The long term solution is to extend to Sysl return syntax thus:

    /rest?method=flickr%2Efavorites%2EgetContext:
        GET ?api_key=string&photo_id=string&user_id=string?:
            | Returns next and previous favorites for a photo in a user's
            | favorites
            return ok <:
                count <: object_object_count?:
                    @json_tag = "count"
                nextphoto <: ContextPhoto?:
                    @json_tag = "nextphoto"
                prevphoto <: ContextPhoto?:
                    @json_tag = "prevphoto"
                stat <: Stat?:
                    @json_tag = "stat"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement import Issues relating to importing other formats into Sysl. P0 Highest priority: important or urgent
Projects
None yet
Development

No branches or pull requests

3 participants