[FOLIO-2169] SPIKE investigate schema migrations in platform-core storage modules Created: 16/Jul/19 Updated: 03/Jun/20 Resolved: 23/Aug/19 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Jakub Skoczen | Assignee: | Taras Spashchenko |
| Resolution: | Done | Votes: | 0 |
| Labels: | platform-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||
| Sprint: | CP: sprint 70, CP: sprint 69, CP: sprint 68 | ||||||||||||
| Story Points: | 5 | ||||||||||||
| Development Team: | Core: Platform | ||||||||||||
| Description |
|
Problem statement FOLIO offers the following facilities for schema upgrades:
What has not been sufficiently tested and verified is the complete flow for performing a module upgrade in a running FOLIO environment that includes a, potentially breaking, schema change. This process should include automatic migration of the existing data (stored in JSON document format) and migration of any DB entities (tables, columns, views, indices, etc). The upgrade procedure should allow for a safe upgrade – it should be possible to restore original data in case the migration goes wrong. See
|
| Comments |
| Comment by Jakub Skoczen [ 01/Aug/19 ] |
|
Taras' document: https://docs.google.com/document/d/1z6rgZK6EVERzRsvTnTKrCHeE5odaNoSJZqVyipuaEFM/edit?pli=1# |
| Comment by Julian Ladisch [ 16/Aug/19 ] |
|
Many modules are based on RMB.
The documentation should mention what migration task are needed for all Okapi modules and which are specific for RMB based modules. There are several way to accomplish this, one possibility is to add the general tasks to the Okapi documentation and the RMB specific tasks to the RMB documentation, with a link to each other. |
| Comment by Taras Spashchenko [ 23/Aug/19 ] |
|
https://github.com/folio-org/raml-module-builder/blob/master/DB-schema-migration.md |