Closed ncrmro closed 3 years ago
Also more interested in yalls thoughts on something like this or if its not an issue in your experence.
I also thought I wanted this when starting with Graphile migrate. What I've realized is that the source of truth is the actual DB state, or a snapshot of that state. In graphile-starter
the snapshot is schema.sql
and it shows the entire state of the DB.
In production you're never going to reset the DB, so you need to always think of what you're doing as a series of changes to the db, described by the migrations, the state of the db is derived from those.
It would be very complex and possibly error prone to attempt to do declarative migrations based on a schema checked into source control.
That is a fair perspective on stuff. I'm just getting to where I have 15 or so migrations with a refactor two on some functions.
A fully migrated database represents the state of the database makes a lot of sense.
Using Pycharm as my IDE (works great with js/typescript) and looking at the built in database browser does pretty much give what I think I was hoping to get out of this issue.
Will leave this open for awhile longer to see if any other perspectives arise or feel free to close it.
Thank you @DylanVann for the perspective!
Feature description
A way to have a source of truth for specific "apps/model", very much how django/rails has an "app" with "model" that represent your tables, functions and types.
Basically standardize automated current.sql from many .sql files in sub-directories.
Motivating example
To make projects in the long term more easily reasoned about for new developers.
Breaking changes
Probably no breaking changes as this might actually be in a package above graphile/migrate.
Supporting development
I [tick all that apply]:
Writing tests and the features are a maybe for me just because of time constraints.