Allow migration files to specify a versionSchema field
#884
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use the migration's `VersionSchema` if it is set, otherwise use the migration's `Name`.
Use the version schema name instead of the migration name for the view name in the ouput message.
If the migration has a `versionSchema` field, use that as the version returned by the `latest_version` function. Otherwise, use the name of the migration.
Ensure that the previous version schema is dropped after the next migration completes, even when the previous version schema sets a non-default version schema name.
This function behaves like `latest_version` but returns the *name* of the latest migration, rather than the name of its version schema. Use the new function: * in `previous_version` because migration parent-child relationships are based on the migration name, not the version schema name. * in `raw_migration` when populating the parent migration for the captured inferred migration, for the same reason as above.
Now that a migration name is not necessarily the same as the version schema name, ensure that this function returns the version schema name of the previous migration, rather than the migration name.
Use `latest_migration` instead of `latest_version` in the SQL statements to ensure that the correct migration name is used. Parent - child relationships use the migration name, not the version schema name.
Ensure that the version schema is dropped after a migration rollback, in both cases where the migration does not set an explicit version schema name and where it does.
Return the name of the latest migration, as oppoosed to the name of the version schema of the latest migration.
Display the latest migration name if there is an active migration rather than the latest version schema name.
This is the partner to the `previous_version` function; this one returns tha **name** of the previous migration, while the other returns the version-schema name of the previous migration.
Return the name of the previous migration for a given schema.
Ensure that we get the name of the previous migration rather than the previous version schema name during the rollback process.
fd35f55 to
3dddf26
Compare
This was referenced Jun 12, 2025
kvch
reviewed
Jun 12, 2025
kvch
requested changes
Jun 12, 2025
For consistency with other fields in migration files.
Merging this branch will decrease overall coverage
Coverage by fileChanged files (no unit tests)
Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code. Changed unit test files
|
kvch
approved these changes
Jun 13, 2025
andrew-farries
added a commit
that referenced
this pull request
Jun 13, 2025
…896) #884 added support for the `version_schema` field in migration files, allowing a migration to specify the name of the version schema that will be created when the migration is applied: ```yaml # migration files can now specify the version schema # name to be created by the migration version_schema: my_version_schema operations: - create_table: name: items columns: - name: id type: serial pk: true - name: name type: varchar(255) ``` When applied as `pgroll start 01_create_table.yaml`, this migration will take the name of its version schema from the migration file: ``` +-----------------------+-------------------+ | Name | Owner | |-----------------------+-------------------| ... | public_my_version_schema | postgres | +-----------------------+-------------------+ ``` If `version_schema` is not specified, the name of the version schema defaults to the filename, as before. --- This PR updates the `pgroll latest` command to take account of this new behaviour, where the version schema name can be decoupled from its filename. Previous behaviour: * `pgroll latest schema`: would return the most recent migration name prefixed with the schema name, eg `public_01_create_table`. * `pgroll latest migration`: would return the most receent migration name without the schema prefix, eg `01_create_table`. New behaviour: * `pgroll latest schema`: returns the version schema name of the most recent migration prefixed with the schema name, eg `public_01_set_by_version_schema_field` * `pgroll latest migration`: returns the name of the most recent migration, without the schema prefix, eg, `01_create_table`. ## Examples Run: ``` pgroll migrate examples/ --complete ``` to apply all example migrations. Now: ```bash # get the **name** of the latest migration applied to the target database $ pgroll latest migration 56_with_version_schema ``` ```bash # get the **version schema name** of the latest migration applied to the target database $ pgroll latest schema public_with_version_schema ``` ```bash # get the **name** of the latest migration in the migrations/ folder $ pgroll latest migration --local examples/ 56_with_version_schema ``` ```bash # get the **version schema name** of the latest migration in the migrations/ folder $ pgroll latest schema --local examples/ public_with_version_schema ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#852 removed support for specifying a migration name via the
namefield in a migration file. While having an unambiguous source of truth for the migration name (the filename) is good, it is still often desirable to decouple the filename from the name of the version schema that the migration will create when applied because filenames:This PR adds support for a new
version_schemafield in migration files that allows the migration author to specify the name of the version schema that the migration will create.Example
Running this migration:
Creates this version schema:
Had the
version_schemafield not been specified in the migration file the version schema would have been:This PR is part of a stack:
versionSchemafield #884 (this PR)VersionSchemafield to operation integration tests #886versionSchemafield #887Part of #882