...
Currently, all the migration scripts for all the services/repos (sunbird-lms-service, group-service, sunbird-notification-service, and sunbird-course-service) are packaged with the cassandra-migration module jar. And all the migration information is stored in the cassandra_migration_version and cassandra_migration_version_counts tables in the sunbird keyspace (used for sunbird-lms-service).
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Background & Problem Statement
If any adopter wanted to build and deploy any one of the services, then the adopter needed to create all the cassandra keyspaces by executing the existing cassandra-migration module, even though the adopter was only adopting a specific service. There is no way for an adopter to only create/migrate specific keyspaces. Furthermore, it is difficult to determine determining which release a specific migration script is introduced in is difficult.
Key Design Problems
Separate the migration script based on respective services/repos.
Remove the bundling on script as a part of cassandra-migration module and variabilise the script path.
Variabilize the keyspace for cassandra-migration module.
Maintain the release version that in which release version that script introduced.
...
Separate all the migration script based on repos and push it to that specific repo.
Mapping of the available keyspaces with repos
Repo Name | Keyspaces |
|---|---|
sunbird-lms-service | sunbird |
groups-service | sunbird_groups |
sunbird-notification-service | sunbird_notifications |
sunbird-course-service | sunbird_courses |
Config
| Code Block | ||
|---|---|---|
| ||
sunbird_cassandra_keyspace=<keyspace_name>
sunbird_cassandra_migration_location="filesystem:<absolute or relative path>/db/migration/cassandra" |