v2.0.0

The major new feature in this release is fixtures. The reason this is a major version is because we've upgraded all the dependencies and the minimum supported Node version is now Node 18, which Migrate will only support until its "end of life" (EOL) date in 2025. Reminder: once a Node.js or PostgreSQL version goes EOL, we no longer support that version, and we may break compatibility with it in a patch release. We only support LTS versions of Node.js and PostgreSQL.

Fixtures

Fixtures live in the migrations/fixtures/ folder and can be included into your migration with --!include comments; this allows you to keep your definitions in a set location (for version control) and include them into the migration when you make changes.

Fixtures can use placeholders such as :DATABASE_VISITOR just like the current.sql migration can.

Fixtures can also --!include other fixtures, though be sure not to create a cycle! (We will throw an error if you do.)

IMPORTANT: fixtures must only affect stateless resources. It would not make sense to add DROP TABLE posts; CREATE TABLE posts (...); into a fixture, as that would result in the table being dropped and recreated each time you --!include it, destroying all your data. Similarly we strongly recommend that you do not use CASCADE in any DROP statements - if a stack of resources needs to be dropped and recreated then do that explicitly to ensure only things you expect to be affected are affected.

Stateless resources: functions, triggers, grants, policies, views, constraints, indexes, etc

Stateless but expensive resources: materialized views, indexes, some constraints, etc

Stateful resources: tables, some operations on composite types used in table columns, etc

Thank you to @jnbarlow for working with me to develop this feature!

Example

In this example you have two fixtures that you've changed, and you will include them into the current.sql migration. Note that the fixtures paths are arbitrary, you can choose your own structure inside that folder.

migrations/fixtures/functions/current_user_id.sql

This is where you would create and manage the current_user_id function. Whenever you make changes to it, ensure you --!include it in your current.sql migration.

create or replace function current_user_id() returns int as $$
  select nullif(current_setting('jwt.claims.user_id', true), '')::int;
$$ language sql stable;
revoke execute on current_user_id() from public;
grant execute on current_user_id() to :DATABASE_VISITOR;

migrations/fixtures/policies/posts.sql

This is where you would create and manage the policies for the posts table. Whenever you make changes to it, ensure you --!include it in your current.sql migration.

drop policy if exists manage_own on posts;
create policy manage_own on posts
  for all
  using (author_id = current_user_id());

drop policy if exists view_all on posts;
create policy view_all on posts
  for select
  using (true);

drop policy if exists admin_delete on posts;
create policy admin_delete on posts
  for delete
  using (current_user_is_admin());

migrations/current.sql

Built in this way, the current.sql migration would only need to contain stateful operations (or expensive operations, like creating indexes); all stateless idempotent operations can be included from their location in fixtures.

--!include functions/current_user_id.sql
--!include policies/posts.sql

v1.4.1

• Fix: Now logs stdout and stderr when a command action fails
• Node v16 and v18 now officially supported
• Node v12 no longer supported, in line with our Node versioning policy

v1.4.0

The --config option now also accepts config files using the .cjs extension (thanks @andrew-w-ross)

v1.3.0

• Added "root" option to "afterReset" hooks of type "command" by @jcgsville
• Lint error fixes by @maxkorp
• Documentation improvements from @c42f and @Tycholiz

v1.2.0

• Integrates @graphile/logger to allow log overrides (thanks @PizzaPartyInc)
• Adds AllowInvalidHash so you can edit the odd legacy commit without having to rebuild the entire stack (use this sparingly!)
• Wider @types/pg support
• Chores

v1.1.0

• Fix issues with symlinks in current/ folder
• Add support for custom path to .gmrc via --config (thanks @ben-pr-p)
• Improve error when creating database fails
• README clarifications (thanks @hegelstad)

v1.0.2

• Ensures that connectionString and rootConnectionString and shadowConnectionString are distinct (thanks @richchurcher)
• Adds a little more detail to error messages
• Fixes the UnhandledPromiseRejectionWarning that can occur in watch mode and makes for messy output
• Documentation fixes (thanks @richchurcher and @christopherscott)

v1.0.1

Fixed an issue with preserving sslrootcert when rewriting connection strings #89 (comment) (thanks @jacobwgillespie)

v1.0.0

Graphile Migrate has proven itself stable; so it's finally time to bump it to v1 🎉

No breaking changes.

New features in this release:

• Added support for .gmrc.js file; alternative to .gmrc JSON5 file.

Fixes:

• graphile-migrate run automatically use GM_DBURL instead of connectionString when called from an action
• Lots of documentation improvements

v0.3.1 - stop scripts using DATABASE_URL

DATABASE_URL is ambiguous when used inside scripts, instead use GM_DBURL.
See #79