Open Sikwan opened 3 years ago
Sorry about that! That looks like it's my bad.
Don't beat yourself up, we still love you.
Although, I just tried from master, and I don't see the issue you're mentioning.
Mind sharing a test? I just redid it and it was the same.
I added this to docparser/user.go:
// TestSadzeih
// @openapi:schema
type TestSadzeih struct {
Signals Signals
}
I ran a make test (which does not run the tests I just realised ^^), and here was the result:
TestSadzeih:
type: object
properties:
Signals:
$ref: '#/components/schemas/'
This was on upstream master.
// @openapi:schema
type TestStruct struct {
Hello string `json:"hello"`
}
// @openapi:schema
type TestArray []TestStruct
Gives me:
TestArray:
type: array
items:
$ref: '#/components/schemas/TestStruct'
TestStruct:
type: object
properties:
hello:
type: string
// @openapi:schema
type TestStruct struct {
Hello string `json:"hello"`
}
// @openapi:schema
type TestWrapStruct struct {
Wrap TestStruct `json:"wrap"`
}
Gives me:
TestStruct:
type: object
properties:
hello:
type: string
TestWrapStruct:
type: object
properties:
wrap:
$ref: '#/components/schemas/TestStruct'
Seems to me your test is not exactly what I am pointing out, you are creating an array of a struct (which works) but not using that new Type as a field in another struct.
Hmm. I got confused by the first example in the description of the PR. I do have the issue when using the slice type in another struct.
Because I messed up in it :D Editing that right now.
So @Sadzeih, what do you think of the implementation?
Hey Guys, I ran into this same issue and I'm glad to see that PR!
I will check on my side and let you know 🤞
Having a nil pointer dereference when generating the doc across my code, investigations in progress.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x40 pc=0x116b5c4]
goroutine 1 [running]:
github.com/alexjomin/openapi-parser/docparser.replaceSchemaNameToCustom(0xc00049d500)
/Users/alexandrejomin/project/openapi-parser/docparser/model.go:383 +0x144
github.com/alexjomin/openapi-parser/docparser.replaceSchemaNameToCustom(0xc00049c3c0)
/Users/alexandrejomin/project/openapi-parser/docparser/model.go:369 +0x86
github.com/alexjomin/openapi-parser/docparser.(*openAPI).composeSpecSchemas(0xc000117380)
/Users/alexandrejomin/project/openapi-parser/docparser/model.go:413 +0x185
github.com/alexjomin/openapi-parser/docparser.(*openAPI).Parse(0xc000117380, {0x2056b9936, 0x100d334}, {0x13f8710, 0x30, 0x30}, {0x1226e64, 0x6}, 0xa8)
/Users/alexandrejomin/project/openapi-parser/docparser/model.go:295 +0xc9
github.com/alexjomin/openapi-parser/cmd.glob..func2(0x13c5e20, {0x1226891, 0x4, 0x4})
/Users/alexandrejomin/project/openapi-parser/cmd/root.go:29 +0x13b
github.com/spf13/cobra.(*Command).execute(0x13c5e20, {0xc000126010, 0x4, 0x4})
/Users/alexandrejomin/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:830 +0x5f8
github.com/spf13/cobra.(*Command).ExecuteC(0x13c5e20)
/Users/alexandrejomin/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914 +0x2fc
github.com/spf13/cobra.(*Command).Execute(...)
/Users/alexandrejomin/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864
github.com/alexjomin/openapi-parser/cmd.Execute()
/Users/alexandrejomin/project/openapi-parser/cmd/root.go:41 +0x25
main.main()
/Users/alexandrejomin/project/openapi-parser/main.go:6 +0x17
Hi guys,
There was a small "regression" (might not have been planned to work before anyway) following commit 2d9c7efd9323134eaeba37dc1003a41fc81b55ee.
What it changed is that now when using aliases for slices, the ref will not be properly filled. Here is a small example, related to the following code:
What it did before:
What it does now:
My changes attempt to fix that, even going a bit further by replacing the alias by the actual struct
What my changes does:
I admit I would go further and remove the Signals schema altogether from the generated documentation but wanted your thoughts on the whole thing before moving further.
@Sadzeih ? @denouche ?
Thanks in advance