Update schema during create table validation #455
Merged
Conversation
This file contains 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
Now that validation can mutate the schema object in memory, we need to reread the schema object from the database before starting DDL operations.
Add the new table to the schema during validation so that subsequent operations in the same migration can assume its existence during their own validation step.
This commit enforces the validation in the test that was previously skipped. This is possible now that the validation of the create table operation updates the schema with the new table so that the validation of the subsequent add column operation can be performed.
kvch
approved these changes
Nov 7, 2024
andrew-farries
added a commit
that referenced
this pull request
Nov 8, 2024
Update the schema during `add_column` operation validation so that
validation of subsequent operations in the same migration can see the
new column.
This means that migrations that add a new column and then perform some
other operation, like adding an index, on that column can be validated
because the new column is visible to the `create_index` operation during
it's validation phase.
This means that the following migration is now able to validate:
```json
{
"name": "43_multiple_ops",
"operations": [
{
"add_column": {
"table": "players",
"column": {
"name": "rating",
"type": "integer",
"comment": "hello world",
"check": {
"name": "rating_check",
"constraint": "rating > 0 AND rating < 100"
},
"nullable": false
}
}
},
{
"create_index": {
"name": "idx_player_rating",
"table": "players",
"columns": [
"rating"
]
}
}
]
}
```
Previously, the new column would not have been visible to the
`create_index` operation and its validation would have failed.
This PR does for the `add_column` operation what #455 did for the
`create_table` operation.
Part of #239
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.
Update the schema during
create_tableoperation validation so that validation of subsequent operations in the same migration can see the new table.This means that migrations that add a new table and then perform some other operation, like adding a column, on that table can be validated because the new table is visible to the
add_columnoperation during it's validation phase.This means that the following migration is now able to validate:
{ "name": "43_multiple_ops", "operations": [ { "create_table": { "name": "players", "columns": [ { "name": "id", "type": "serial", "pk": true }, { "name": "name", "type": "varchar(255)", "check": { "name": "name_length_check", "constraint": "length(name) > 2" } } ] } }, { "add_column": { "table": "players", "column": { "name": "rating", "type": "integer", "comment": "hello world", "check": { "name": "rating_check", "constraint": "rating > 0 AND rating < 100" }, "nullable": true } } } ] }Previously, the new table would not have been visible to the
add_columnoperation and its validation would have failed.In order to make this work the schema needs to be re-read from the target database in between validation and migration start, as the previous assumption that validation would not make changes to the in-memory schema representation no longer holds.
Part of #239