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

Missing package when using struct:pkg:path inside an attribute #3083

Closed
ernesto-jimenez opened this issue Jun 22, 2022 · 0 comments
Closed

Comments

@ernesto-jimenez
Copy link
Contributor

We were extracting some types that we use as attributes into their own package using Meta("struct:pkg:path", "types").

However, when we try to do so, the struct with the generated attribute generates code looking for the struct in the current package rather than the imported types.

Example:

var PkgPathPayloadAttributeDSL = func() {
	var Foo = Type("Foo", func() {
		Attribute("IntField", Int)
		Meta("struct:pkg:path", "foo")
	})
	var Bar = Type("Bar", func() {
		Attribute("Foo", Foo)
	})

	Service("PkgPathPayloadAttributeDSL", func() {
		Method("Foo", func() {
			Payload(Bar)
			Result(Bar)
		})
	})
}

We would expect generated code for Bar to be something like:

type Bar struct {
    Foo *types.Foo
}

However, it generates this instead:

type Bar struct {
    Foo Foo
}
ernesto-jimenez pushed a commit to ernesto-jimenez/goa that referenced this issue Jun 28, 2022
…pkg:path`

What was the issue?

What was meant to be a check on the parentPkg to avoid recursive
definitions wasn't actually checking the parent package, but the package
of the field itself.

It was a bug that got introduced in goadesign#3022 and never worked as expected.

Solution:

Injecting the parent package for the initial definition seems to address
this.
raphael pushed a commit that referenced this issue Jul 12, 2022
What was the issue?

What was meant to be a check on the parentPkg to avoid recursive
definitions wasn't actually checking the parent package, but the package
of the field itself.

It was a bug that got introduced in #3022 and never worked as expected.

Solution:

Injecting the parent package for the initial definition seems to address
this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant