Add support for updating materialized views #102
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
| "'drop_view' followed by 'create_view', being sure to also recreate "\ | ||
| "any previously-existing indexes." | ||
| Scenic.database.reapplying_indexes(on: name) do | ||
| drop_view(name, revert_to_version: revert_to_version, materialized: materialized) |
There was a problem hiding this comment.
I'm also fine with this. I feel like readability is better with the longer line.
derekprior
force-pushed
the
dp-update-materialized-views
branch
from
34b7671
to
7570446
Compare
| echo "[success]" | ||
|
|
||
| echo "rails destroy scenic:view search --materialized" | ||
| echo "rails destroy scenic:model search --materialized" |
There was a problem hiding this comment.
Looks like this line should be moved below 117, and the scenic:view echo should stay here.
There was a problem hiding this comment.
What we're actually testing here is the model destroy since we never tested that previously. We have to first do a view destroy so that the second version of the view is deleted.
Updating materialized views used to be an error because providing a new
definition for a materialized view requires dropping and recreating it.
This will cause any indexes on the old materialized view to be dropped.
For this reason, we suggested that users manually `drop_view`,
`create_view` and `add_index`. This is a frustrating user experience.
This changes view updates to record any indexes that were in place
before the `drop_view` and then re-create those indexes once the new
materialized view is in place. Any indexes that are now invalid
(most-likely because the column no longer exists) will be dropped. This
behavior is similar to what happens when you alter the schema of a
table, so I do not believe it to be surprising.
We log the results of each index creation for the users information in
the migration output. For example:
```
== 20151228201117 UpdateSearchesToVersion2: migrating =========================
-- update_view(:searches, {:version=>2, :revert_to_version=>1, :materialized=>true})
-> index 'searches_test_1' on 'searches' has been recreated
-> index 'searches_test_2' on 'searches' is no longer valid and has been dropped.
-> 0.0148s
== 20151228201117 UpdateSearchesToVersion2: migrated (0.0149s) ================
```
Closes #98
derekprior
force-pushed
the
dp-update-materialized-views
branch
from
7570446
to
d804934
Compare
| "index '#{index.index_name}' on '#{index.object_name}' has been recreated" | ||
| rescue ActiveRecord::StatementInvalid | ||
| connection.execute("ROLLBACK TO SAVEPOINT #{index.index_name}") | ||
| "index '#{index.index_name}' on '#{index.object_name}' is no longer valid and has been dropped." |
|
@calebthompson I moved the PG specific code into the adapter. I think there's some further refactoring (as pointed out by hound's ABC warning here) to slim down and break up the adapter, but I'd like to attack that in a separate refactoring. |
|
lgtm |
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.
Updating materialized views used to be an error because providing a new
definition for a materialized view requires dropping and recreating it.
This will cause any indexes on the old materialized view to be dropped.
For this reason, we suggested that users manually
drop_view,create_viewandadd_index. This is a frustrating user experience.This changes view updates to record any indexes that were in place
before the
drop_viewand then re-create those indexes once the newmaterialized view is in place. Any indexes that are now invalid
(most-likely because the column no longer exists) will be dropped. This
behavior is similar to what happens when you alter the schema of a
table, so I do not believe it to be surprising.
We log the results of each index creation for the users information in
the migration output. For example:
Closes #98