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

Add go_package cmd param #413

Open
DrBlury opened this issue Oct 21, 2024 · 2 comments
Open

Add go_package cmd param #413

DrBlury opened this issue Oct 21, 2024 · 2 comments
Labels

Comments

@DrBlury
Copy link

DrBlury commented Oct 21, 2024

I need to generate my go structs in a different package. The package name is repo.
Currently the generator will always generate with package name model, enum or table.

Solution (preferred):
I'd like another parameter to be added that allows me to define the go package name for the generated files. (Or multiple parameters for each package)

jet -dsn=postgres://$APP_DATABASE_USER:$APP_DATABASE_PASSWORD@localhost:$APP_DATABASE_PORT/$APP_DATABASE_NAME?sslmode=disable -schema=public -path=./.gen

-gopkgmodel=entities, -gopkgtable=something, -gopkgenum=dbenums

Something like this would help a lot!

#208 does not solve my issue. I think this should be easily accessible via CLI.

@safaci2000
Copy link
Contributor

I'm not sure I understand why that particular behavior matters, then again, I don't think there's anything preventing that feature.

That being said....

@go-jet what do you think about simply exposing the 'templates' as files the user can override?

Right now, file_templates.go contains all these static data. You can use embed.FS and have a fallback to read from a predefined directory like jet_templates/table.tmpl.go

It would allow users to add their own customizations without being forced to commit the change upstream and wait for a release?

@go-jet
Copy link
Owner

go-jet commented Oct 28, 2024

@go-jet what do you think about simply exposing the 'templates' as files the user can override?

Exposing template file will make them part of the public API, which entails a commitment to maintain and support them unchanged until the next major release. There are also numerous FuncMap functions, not just static data. Exposing these internal implementation details could limit future refactoring options, as changes would need to avoid breaking the public contract. For the time being, I'd prefer to keep template private.

If a developer needs to customize the template, they always have the option to fork the project and implement any necessary modifications.

@go-jet go-jet added the good first issue Good for newcomers label Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants
@safaci2000 @DrBlury @go-jet and others