Here's some documentation covering the questions I asked in #121.
One point we didn't discuss in #121 was how to initialize new production and development databases with the initial_schema.sql already in use in production. In our production tooling I found graphile-migrate reset too scary to use for applying initial_schema.sql, as our application is occasionally deployed to existing database servers. In theory this should be ok as we'd be using a schema name not already in use. But in practice I wanted some extra defense against things going wrong, so I've added an alternative suggestion on how to do this.
(Possibly this suggests a feature for the future — allow a safe graphile-migrate reset without -f, provided the schema doesn't already exist or is empty.)
c42f
commented
3 years ago
Here's some documentation covering the questions I asked in #121.
One point we didn't discuss in #121 was how to initialize new production and development databases with the
initial_schema.sqlalready in use in production. In our production tooling I foundgraphile-migrate resettoo scary to use for applyinginitial_schema.sql, as our application is occasionally deployed to existing database servers. In theory this should be ok as we'd be using a schema name not already in use. But in practice I wanted some extra defense against things going wrong, so I've added an alternative suggestion on how to do this.(Possibly this suggests a feature for the future — allow a safe
graphile-migrate resetwithout-f, provided the schema doesn't already exist or is empty.)