I have an app in Spring Boot and use Mogock with MongoDB. Recently, I made a big refactoring and changed many class names and collection names. What I used to have before refactoring is an entity FooDb:
@Document("foo")
public class FooDb {
@Id
private String id;
...
}
and some interface:
@Repository
public interface FooRepository extends MongoRepository<FooDb, String> { ... }
and migration file:
@ChangeUnit(order="001, ...)
public class CreateFooChangelog {
...
@Execution
public void migration(FooRepository repository) {
repository.save(...);
}
}
During refactoring I only changed names of collections and classes. Their structure is the same:
@Document("bar")
public class BarDb {
@Id
private String id;
...
}
@Repository
public interface BarRepository extends MongoRepository<BarDb, String> { ... }
However, now I am not sure what to do with existing migration file. Is it good idea to modify existing migration files? I will definitely need to modify it because Foo* classes no longer exist in code.
I can think of solution like this: if there exists a foo collection it needs to be renamed to bar and if not, I need to initialize bar with some default data. Then I could try to modify this migration file like this:
@ChangeUnit(order="001", ...)
public class CreateBarChangelog {
...
@Execution
public void migration(BarRepository repository) {
// if foo exists, rename it to bar
// else: repository.save(...);
}
}
Is this the right approach in this scenario or is there a better solution?
There are a couple of aspects to discuss.
Is it good idea to modify existing migration files? Mongock, as any other migration tool of the kind, it's designed to take a database from state S(0) to state S(n) by applying a sequence of what we call changeUnits(migration changes) that will make the database go through all the states S(0),S(1),..,S(n-1),S(n). This is specially useful when deploying the application from scratch in new environments. Taking this into account, this renaming process should be another state S(n+1) more. So the answer is NO, we suggest not to amend the existing changeUnits(for this reason)
I will definitely need to modify it because Foo__ classes no longer exist in code This is the reason why we suggest not to use repositories and domain classes in changeUnits and the MongoTemplate(or driver classes) directly instead. At this point, you have three options:
Changing the migration files in the project: Not recommended because these files(changeUnits) should remain unchanged as much as possible.
Keeping the deprecated classes in the project: Not recommended because force you to keep deprecated code in your project
Moving these deprecated classes to a separated library and bring it to your project via maven/gradle. This is not 100% ideal neither, but the one we recommend because, among the three options, it provides the best balance(the changeUnits remain unchanged and your project can evolve without maintaining deprecated classes)
In conclusion, we suggest.