Automated migrations vs multiple versions

Questions / Help
1

I am working currently on an application that performs some automated tasks and saves data in a specific format in the database. The idea of the application is that it is developed with agile approach, meaning that the logic of the tasks and the format of the data will always change in the future, and at the same time the format of the data is important because there are some templates that need to display that data.

I was thinking about 2 approaches:

  1. Version the data and the display views, so each format of the data can be displayed accordingly - the problem with this approach is that you need to keep old versions source code, witch can get hairy in the long run;
  2. Create data migration scripts - this option is more appealing at first, however the requirement of the project is that it should work on self-hosted instances and doing more tricky manual migrations is out of the question.

This is a pretty common problem nowadays, maybe there are some standardized approaches or libraries to deal with these problems? Any ideas or advices?

2

https://leanpub.com/esversioning/read

While is was created to aid with event sourced systems I found this a valuable discussion on the topic no matter the underlying system. In the end I think event sourcing is just a more explicit form of what happens in CRUD as well. Event sourcing just doesn’t throw away the history immediately and continues to use it as it’s source of truth.

2 Likes
3

You are a lifesaver! The book is great and covers a lot of interesting cases, from multiple points of view. This opened a whole new can of worms.

I am thinking that in my use-case runtime data format transformation with a single template (for latest version) is the way to go, a good balance between migration safety and quantity of source-code stored in the project.