Play 2.5.18 - Database Evolutions behaviour

Play Framework
1

Hi everyone,

hope this is the right place to ask, since i was redirected here from the Play Framework Google Group.

We have a Play Project (Version 2.5.18) using Evolutions to apply changes to the database schema. Of course we have disabled the “auto apply” for down scripts on our production systems, but now some rather strange issue occured.
Two identical instances of our application, each using their own database, have the same revisions of evolution scripts applied. We checked this in the play_evolutions table: Status is “applied”, the hash, apply_script and revert_script are absolutely identical. They are also identical with the scripts in the physical sql files which are deployed on the server.
But when we start one of the systems we get the error “p.a.d.e.ApplicationEvolutions - Your production database [default] needs evolutions, including downs!”. The other application instance works fine. The entries (hash, and scripts) in the “play_evolutions” are even the same in both databases.
Certainly we can solve this by executing the down scripts manually, deleting the entries in the “play_evolutions” table and letting play let the database “evolve” again :slight_smile:

Now I ask myself, why do we get the error on application startup for only one system, since the entries in the “play_evolutions” table are valid and matching with the physical sql scripts.

I also tried to find the logic how Evolutions defines the conditions for applying down scripts, but it seems that not all relevant source files from Evolutions are accessable in the GitHub Repository.

So the concrete question is, how does Evolutions decide, when to apply down scripts?

Thanks in advance.

Best regards
Domm

1 Like
2

It’s been a week now and no answer - so no one knows how evolutions really works?

for those few who could be interessted in this topic: to “reproduce” the mentioned behaviour, you need two instances (+ databases) of your application. make some change to the SQL scripts and just deploy the changes on only one system.
evolutions know takes care of applying the database changes and will generate a new hash for up and down scripts in the table “play_evolutions”.
copy the hash and every content (apply_script, revert_script, timestamp) to your second systems database. the deployed system can start and the “manually evolved” system will throw an error, as discribed above.

1 Like