78 - Fix checksum migration issue #79
Conversation
…nges in new SQL script - Migrations files are signed with a md5 sum in the DB to avoid modifications. The SQL file was restored to its original state - The changes were moved to a new a script, but because is not possible to add a new column to a materialized view, the change was applied recreating the view - The changes to the view `raw_contacts` that was rolled back was redundant, because the same migration to add 'contact' to the list of values for `doc->>'type'` was added in an earlier migration script
|
|
||
|
|
||
| ## Known issues |
There was a problem hiding this comment.
We should really have a release-notes.md to contain this information, instead of the readme.
There was a problem hiding this comment.
Agree. @garethbowen do you want me to prepare a new PR for the release ? I can create there the release note file and move this content. The release version should be 3.2.1, right?
| -- NOTE: The recreation of the view above caused 4 other views to be dropped in cascade, | ||
| -- here are the scripts to recreate them: | ||
|
|
||
| CREATE VIEW contactview_hospital AS |
There was a problem hiding this comment.
Super sad we have to have all this duplicated code.
There was a problem hiding this comment.
Yes, next time we use Postgrator to mantain views, may be better to use *.js script to reuse better the SQL scripts.
Also it is sad that Postgres does not allow to add a column in a view without the need to recreate it manually, whether the engine needs to recreate the entirely view or not, it should be an internal decision made by the engine.
There was a problem hiding this comment.
I actually read a little around this, and people were complaining that they can't update materialized views in pgadmin - which is arguably probably even more popular than Postgrator. It could be pgadmin has improved since those posts though, but my point is that this seems like it is a common problem with other pg tools and not something that's easily automated.
There was a problem hiding this comment.
Yes the problem is that Postgres does not support ALTER VIEW xxx ADD COLUMN ... like in tables does. It does allow to do some ALTER changes but the most basic one that is to add a column is not supported.
There was a problem hiding this comment.
... and my point is that even if that is not possible without the recreation of the whole materialized view, that should be an implementation detail for the engine, not for the user, Postgres could support ALTER VIEW xxx ADD COLUMN ... syntax, adding a note in the documentation, like: if you add a column in a materialized view internally the engine will recreate the whole view and dependent views and indexes, and that can take a while, use with precaution ...
There was a problem hiding this comment.
yea, I agree it's a less then ideal situation.
|
|
||
| -- NOTE: The recreation of the view above caused 4 other views to be dropped in cascade, | ||
| -- here are the scripts to recreate them: | ||
|
|
There was a problem hiding this comment.
I think we should link to the original migration that created each of these (including the line numbers). Something like: https://github.com/medic/medic-couch2pg/blob/master/libs/analytics/migrations/201711071603.do.2635-removeNestedContactReferences.sql#L26
There was a problem hiding this comment.
Yes better to keep track of that, adding...
Co-authored-by: Diana Barsan <[email protected]>
Co-authored-by: Diana Barsan <[email protected]>
… into 78-fix-checksum-migration-issue
Issue: #78
Rollback changes in immutable migration file and applied intended changes in new SQL script:
raw_contactsthat was rolled back was redundant, because the same migration to add 'contact' to the list of values fordoc->>'type'was added in an earlier migration script.