DEV Community

Discussion on: How to Use Liquibase to Update the Schema of Your JHipster Application

Collapse
 
avdev4j profile image
Anthony Viard 🥑

Hi @codenameone ,
I can understand reviewing process can make merging painful when you deal with DB schema updating.

I used Flyway in the past and faced the same issue. If somebody had to change the schema before me, this meant updating my SQL scripts to match with the new requirements.

Liquibase uses Changelogs to isolate changes (and even changesets) so I guess only the "master file" has to be updated, isn't it?
However, if two scripts change the same table, it could be a mess and force the developer to update his own changelog.

This is why I would more rethink the way we are developing the features. As I said, in the past I faced that (with Flyway) and we decided to evaluate, before each sprint, which story could be an issue about schema updating.
Finally, it was successful for us because we avoided starting 2 stories that could end to conflicts, or we defined priorities between both. But it's not the only source of truth and it really depends on teams (teams should choose the best solution they are comfortable with).

Two questions for you:

  • Why did you find Liquibase painful to read/understand?
  • How Flyway helps you to improve that?
Collapse
 
codenameone profile image
Shai Almog

Flyway is just SQL commands. It's really simple to read in code reviews and if there's a conflict it's a pain but it can all be fixed.

As you said, Liquibase conflicts are really hard to read and follow. Then redoing the process is painful.

I agree that we should segment DB features better. Unfortunately that wasn't my call on the team. The features are sometimes concurrent and backported so you end up with different schemas all over the place and people going back/forth between schemas.
All the teams are vertical/feature oriented so everyone touches the database all the time.

I can't say we love Flyway. It just fails in a way that's easier to understand.