External x-go-type imports not resolved for arrays and references

[moskal91]

Problem statement

Ok, after few days of debugging I give up. Problem with imports using x-go-type still exists after my changes, is seems that it fixed only imports when flat object definition is used.

File: get_user_obj_ref_responses.go - FAIL

import (
	"net/http"

	"github.com/go-openapi/runtime"

        // myalias3 "github.com/user/externalrepo/pkg/models" <--- MISSING!
)

With swagger 0.16.0 same result.

File: get_user_obj_flat_responses.go - CORRECT

import (
	"net/http"

	"github.com/go-openapi/runtime"

	myalias4 "github.com/user/externalrepo/pkg/models"
)

With swagger 0.16.0 import MISSING

File: get_users_arr_ref_responses.go - FAIL

import (
	"net/http"

	"github.com/go-openapi/runtime"

	// myalias1 "github.com/user/externalrepo/pkg/models" <-- MISSING!
)

With swagger 0.16.0 same result.

File: get_users_arr_flat_responses.go - FAIL

import (
	"net/http"

	"github.com/go-openapi/runtime"
        // myalias2 "github.com/user/externalrepo/pkg/models" <-- MISSING!
)

With swagger 0.16.0 same result.

Swagger specification

swagger: '2.0'
info:
  title: 'x-go-type issues'
  version: '1.0'
paths:
  /users_arr_ref:
    get:
      responses:
        200:
          description: OK
          schema:
            $ref: '#/definitions/UsersArrayRef'
  /users_arr_flat:
    get:
      responses:
        200:
          description: OK
          schema:
            $ref: '#/definitions/UsersArrayFlat'
  /user_obj_ref:
    get:
      responses:
        200:
          description: OK
          schema:
            $ref: '#/definitions/UserObjectRef'
  /user_obj_flat:
    get:
      responses:
        200:
          description: OK
          schema:
            $ref: '#/definitions/UserObjectFlat'
definitions:
  User:
    type: object
    properties:
      name:
        type: string
      age:
        type: integer
  UsersArrayRef:
    type: array
    items:
       $ref: '#/definitions/User'
    x-go-type:
      import:
        alias: myalias1
        package: 'github.com/user/externalrepo/pkg/models'
      type: ExtUsers
  UsersArrayFlat:
    type: array
    items:
      type: object
      properties:
        name:
          type: string
        age:
          type: integer
    x-go-type:
      import:
        alias: myalias2
        package: 'github.com/user/externalrepo/pkg/models'
      type: ExtUsersFlat
  UserObjectRef:
    $ref: '#/definitions/User'
    x-go-type:
      import:
        alias: myalias3
        package: 'github.com/user/externalrepo/pkg/models'
      type: ExtUser
  UserObjectFlat:
    type: object
    properties:
      name:
        type: string
      age:
        type: integer
    x-go-type:
      import:
        alias: myalias4
        package: 'github.com/user/externalrepo/pkg/models'
      type: ExtUserFlat

Steps to reproduce

swagger generate server -f swagger.yml

Environment

swagger version: master
go version: 1.11
OS: Ubuntu 18.04

[fredbi]

Does this means that the PR you delivered does not work? It is not clear to me.

I think your examples are related specifically to models reused in the generation of the "operations" package.
To move on further, specifying the aliased package name here (and in the other places where you detect external) is probably what is used by models reused in operations. In the following, when left blank, this means the "models" alias is used.

go-swagger/generator/model.go

Line 211 in e13f855

resolver := newTypeResolver("", specDoc)

[moskal91]

Nevermind, I somehow replaced "alias" with "type" in my swagger spec. Sorry, too much digging for today.

[moskal91]

Ok, I found out what issue I had, I'll update it.

[moskal91]

It seems that my PRs fixed imports only for flat objects, don't know why. My knowledge about go-swagger generator code is probably too basic to fix it now. I hope somebody can help.

Here is original commit which introduced x-go-type feature:
759dbbc

I thought that ma PR #1705 allowing whole model definition hierarchy to build (removed return nil, nil from beginning makeGenDefinitionHierarchy when x-go-type detected) and then adding Pkg and PkgAlias to builder imports will resolve the problem, but it seems that something else is wrong.

[fredbi]

as I said, there is a special provision with type resolver to use models in the operations package from the models package. This occurs when body or response use a schema which is already available, e.g. in the models package (default).
This is to distinguish with the case when the model is generated in the operations package itself (e.g. inlining).
So the new alias has to be specified here when first resolving the type in models.go. Otherwise, it defaults to "models.{gotype}"

[moskal91]

I discovered that adding

tpe, pkg, alias := knownDefGoType(t.ModelName, *schema, t.goTypeName)
if tpe != "" {
	result.GoType = tpe
	result.Pkg = pkg
	result.PkgAlias = alias
}

before return statement here:

go-swagger/generator/types.go

Lines 630 to 633 in e13f855

	}
	debugLog("returning after ref")
	return
	}

solves import problem also for get_user_obj_ref_responses.go (see issue description), but still wrong imports in arrays. Maybe it would be helpful.

[fredbi]

I don't think the problem really lies with arrays, but more likely with arrays or maps of models
declared in the operation package (e.g. param body or response is array or map of an already existing model type)

[fredbi]

Requalified as bug. Could reproduce. Will look into it.