Schema migration in practice frequently includes not only schema migration, but also data changes. For instance in case of creating of additional table to existing one for new select support, apart from creation of new table, we also need to fill it with data from primary table.
What if, hypothetically, tool could accept some implementations of interface with two methods:
getVersion, which specs, after which schema migration script it should be executed
apply, data migration execution scenario itself
Eventually, on script execution, tool will get data migration, assigned to script and invoke it and after that, migration is considered as executed successfully
Feature request is based on personal implementation of data migration, but it is executed after schema migration with it's own tables, containing migrations and leaders information. In practice, if you use spring data repositories in data migration code, you should support old migrations, as models change alongside with schema, which leads to compilation problems. It is easier to delete them later. Alternatively, you can operate with cqlTemplate, playing around with non-mapped result set, in this case you write code only once, but code itself is more complex. In any case, with such proposal, user is not forced to some specific approach, it is up to him to decide, what and how to operate on schema migration #X .
Schema migration in practice frequently includes not only schema migration, but also data changes. For instance in case of creating of additional table to existing one for new select support, apart from creation of new table, we also need to fill it with data from primary table.
What if, hypothetically, tool could accept some implementations of interface with two methods:
Eventually, on script execution, tool will get data migration, assigned to script and invoke it and after that, migration is considered as executed successfully
Feature request is based on personal implementation of data migration, but it is executed after schema migration with it's own tables, containing migrations and leaders information. In practice, if you use spring data repositories in data migration code, you should support old migrations, as models change alongside with schema, which leads to compilation problems. It is easier to delete them later. Alternatively, you can operate with cqlTemplate, playing around with non-mapped result set, in this case you write code only once, but code itself is more complex. In any case, with such proposal, user is not forced to some specific approach, it is up to him to decide, what and how to operate on schema migration #X .