Swag: Commit 67cb0975876f155725732d1aeb87fb8310e6aaf9 breaks parsing of external types

Created on 14 Oct 2020  路  7Comments  路  Source: swaggo/swag

Describe the bug
When running a newer version than 67cb0975876f155725732d1aeb87fb8310e6aaf9 swag init fails when using types from external packages. In my case I use the type sql.NullInt32 from database/sql.

I did a git bisect and it concluded that the issue started with commit 67cb0975876f155725732d1aeb87fb8310e6aaf9 by @sdghchj

stamp_2020-10-14_085136

This issue could be related to #802 as well

To Reproduce
I have not been able to figure out how to reproduce this. I tried with the basic example and changed the datatype to sql.NullInt32 but it didn't fail.

I have a repo with the source code that generates the issue. So I suppose the easiest way to reproduce it is to clone this repo (https://github.com/stamp/adreso-lab) and run swag init with a newer version than 67cb0975876f155725732d1aeb87fb8310e6aaf9

Expected behavior
Successfull generation of the swagger json and yaml files

Screenshots
Screenshot of a failing swag init
stamp_2020-10-14_085519
Screenshot of a successfull swag init
stamp_2020-10-14_085546

Your swag version
df209afeed2334a97c83aff34ea7abcad85c31f6 -> 01fb3185e07ce397a62290d49e7513de9f2f3716

Your go version
go1.14

Desktop (please complete the following information):

  • OS: linux
  • Browser: chrome
  • Version: 86

Additional context
The 67cb0975876f155725732d1aeb87fb8310e6aaf9 commit is a massive refactor so I think its best if the author helps out ironing out the issue.

Most helpful comment

It did help :)

Maybe we should improve on the error message then? Like give the user a hint to use swaggertype to manually define it?

PR is welcome.

All 7 comments

Yes, for some reason, I removed that feature which can be achieved alternatively by swaggertype if it is of primitive type

I have now updated the issue with a link to a repo with the broken code. I tried to clean it up to make it as small as possible.

The repo can be found here: https://github.com/stamp/adreso-lab

type AddressForm struct {
    IP       string        `json:"ip_address" gorm:"type:varchar(15);not null"`
    Mac      string        `json:"mac" gorm:"type:varchar(17);not null"`
    Hostname string        `json:"hostname" gorm:"type:varchar(255)"`
    Reserved bool          `json:"reserved" gorm:"type:bool"`
    PoolID   sql.NullInt32 `json:"pool_id" gorm:"type:int(11)" swaggertype:"integer"`
}

It did help :)

Maybe we should improve on the error message then? Like give the user a hint to use swaggertype to manually define it?

Why the feature of parsing external types is abandoned?

  1. It only works for external types written directly in API comments, but not works when as members in a struct.
  2. If external types are complex structs consisting of other dependent external types, it may fail when parsing.
  3. So it is an incomplete feature, I think. And, an alternative way is to use swaggertype ,--parseDependency, --parseInternal
  4. After be refactored, to locate a type correctly, its mechanism of finding type definitions has changed: load package first, then search for type definitions.

I totally understand! Good call.

Using swaggerType solved my issue so I'm happy. The reason for my comment about improving the error message was just to help the next developer facing the same issue :)

Thank you for your help and all the work with this great tool! @sdghchj

It did help :)

Maybe we should improve on the error message then? Like give the user a hint to use swaggertype to manually define it?

PR is welcome.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

piwan picture piwan  路  6Comments

welenlin picture welenlin  路  3Comments

wuhuizuo picture wuhuizuo  路  4Comments

dmirubtsov picture dmirubtsov  路  7Comments

kirillDanshin picture kirillDanshin  路  3Comments