Introduction

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 table in the sunbird keyspace (used for sunbird-lms-service).

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 which release a specific migration script is introduced in.

Key Design Problems

1. Separate the migration script based on respective services/repos.

2. Remove the bundling on script as a part of cassandra-migration module and variabilise the script path.

3. Variabilize the keyspace for cassandra-migration module.

4. Maintain the release version that in which release version that script introduced.

Design

• Add the release version in the filename.

  V1.<migration_version>_cassandra-<release_version>.cql
  
  e.g.
  V1.1_cassandra-release-5.2.0.cql
  
  

cqlsh> SELECT * FROM sunbird_groups.cassandra_migration_version;

 version | checksum    | description             | execution_time | installed_by | installed_on                    | installed_rank | script                           | success | type | version_rank
---------+-------------+-------------------------+----------------+--------------+---------------------------------+----------------+----------------------------------+---------+------+--------------
     1.1 | -1118871967 | cassandra-release-5.2.0 |              6 |    cassandra | 2023-02-06 05:04:39.893000+0000 |              1 | V1.1_cassandra-release-5.2.0.cql |    True |  CQL |            1