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

Remove runtime.Caller from schema.DotGo #14705

Merged
merged 9 commits into from
Dec 20, 2024

Conversation

markylaing
Copy link
Contributor

This is an alternative to #14704

I didn't understand why runtime.Caller was required. It was because of where the SchemaDotGo functions were defined in the node and cluster packages.

We can instead just split the go:generate directives into their respective packages so that invocation there will cause the schema.go files to be created in the current directory.

As an aside, since lxd-generate is used by micro* packages, I'd also be in favour of removing the schema subcommand from it, as it only supports generating the LXD node or cluster schemas.

There is no reason to get the calling function. We can
expect the filename and package to be passed in.

Signed-off-by: Mark Laing <[email protected]>
Note that we don't need the full file path to the `schema.go` file
because we'll have a generate directive inside this directory.

Signed-off-by: Mark Laing <[email protected]>
Note that we don't need the full file path to the `schema.go` file
because we'll have a generate directive inside this directory.

Signed-off-by: Mark Laing <[email protected]>
@markylaing markylaing added the Improvement Improve to current situation label Dec 20, 2024
@markylaing markylaing self-assigned this Dec 20, 2024
Copy link
Member

@tomponline tomponline left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah this is nicer. Thanks.

I don't know the history of lxd-generate so dont know why it wasnt done like this originally.

Does this break micro* usage of it though?

@tomponline
Copy link
Member

I'd also be in favour of removing the schema subcommand from it, as it only supports generating the LXD node or cluster schemas

Removing the schema sub-command from what? micro* or from lxd-generate?

If its removed how will the schema get generated in lxd?

@tomponline tomponline merged commit 54b8d16 into canonical:main Dec 20, 2024
26 checks passed
@markylaing
Copy link
Contributor Author

I don't know the history of lxd-generate so dont know why it wasnt done like this originally.

Who could say!

Does this break micro* usage of it though?

lxd-generate db schema only does one thing, it generates the LXD cluster and node schemas. So if micro* are using it I would be quite surprised.

The schema.DotGo function may be used elsewhere but I couldn't find any evidence of this. I don't think any microcluster Apps have a reason for generating a fresh schema because the design is predicated on applying schema updates at startup to the core tables.

Removing the schema sub-command from what? micro* or from lxd-generate?

From lxd-generate.

If its removed how will the schema get generated in lxd?

You could have a tiny freshschema package in lxd/db/{cluster,node} that has a main function that calls (lxd/db/{cluster,node}).SchemaDotGo and change the generation directive to //go:generate go run ./freshschema/main.go.

@tomponline
Copy link
Member

You could have a tiny freshschema package in lxd/db/{cluster,node} that has a main function that calls (lxd/db/{cluster,node}).SchemaDotGo and change the generation directive to //go:generate go run ./freshschema/main.go

I see.

Could you have a single freshchema program in say, lxd/db and call it via go run ../freshschema/main.go and have it take an argument for the schema to generate?

@markylaing
Copy link
Contributor Author

Could you have a single freshchema program in say, lxd/db and call it via go run ../freshschema/main.go and have it take an argument for the schema to generate?

Yeah I don't see why not :)

@tomponline
Copy link
Member

Yeah I don't see why not :)

Cool, go for it, thanks

tomponline added a commit that referenced this pull request Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Improve to current situation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants