Generate models from a set of migration files

[HerrNaN]

When I want to make a change to my database (add/update/delete a column/table etc.) I want to be able to generate the models to use when writing the data layer application code without having to actually spin up a database instance to generate the models from.

Surely the information needed to generate the models is contained within these files (or am I missing something?)

[go-jet]

Hi @HerrNaN . After migration is applied to database you'll need to run jet generator to update sql builder and model files.

Surely the information needed to generate the models is contained within these files (or am I missing something?)

Jet generator works only with a running database, and it doesn't try to parse files. Off course running database should be local test database.

Why is it a problem to have a running local database?

[HerrNaN]

Hi @go-jet!

For me it's not so much of a problem to have a running db than it is an inconvenience. I cannot think of a scenario where i couldn't spin up a db but since the db is built from the migration files I though it would be neat if I could generate the models from those.

I understand that the generator today only works on a running database and maybe there is a reason why (although I'm not involved enough to know what). This is simply a feature request to support the generation of files from a set of migrations files so that I don't have to spin up a db only to run the generation upon it.

Maybe this is out of scope for this project, or at least currently but I thought I would throw the idea out there :)

[go-jet]

There is no point of reinventing the wheel. Database vendors are already doing the parsing, and we are just asking running database instance for the current state of information schema. Also implementing DDL for every possible SQL dialect is not a trivial task.

[adrien-owkin]

in Java I really enjoyed using jOOQ because types and query builders were generated from the migration files. I agree with @HerrNaN it would less overhead, less dependency and setup this way but a more important thing for me is that it is less error prone since there is less possibility to generate types against an outdated schema. Yes, one could be using an old git revision but same goes with running your DB to have a live schema to use with jet.

Maybe we could use in-memory databases like https://pkg.go.dev/github.com/fergusstrange/embedded-postgres to have a way to run jet against migration files:

1. run the migrations against the in-mem db
2. run jet

[go-jet]

Maybe we could use in-memory databases like https://pkg.go.dev/github.com/fergusstrange/embedded-postgres to have a way to run jet against migration files:

Haven't used embedded-postgres library yet, but if it accepts standard postgres dsn you can already use jet to connect and generate jet types from such in-memory database.

To guard yourself of using stale generated types, you can add a pre-run jet generator step in your local environment. Also you can add a step in a CI build, where build runs jet generator and if there are any git differences fails the build.