Hello friends and Happy Christmas to all.
Finally I found an answer on my first question. Yes, the database scheme can change with updates, and it is exactly what was happened in the case of my server. To detect the database change I used the pgquarrel tool, and compared my production server database (obviously the old one) with the database of the up to date KoboDocker clean install. As long as my production server for the moment make a step from the pilot project to the official investigation instrument, the question opened in this thread is important for me personally.
To automate investigation of the KoboDocker migration procedure the https://github.com/YKolokoltsev/KoboAdminTools script pack was created. In the KoboAdminTools description I tried to present the clean update recipes, and invite you to exchange your experience about possible special techniques in KoboDocker administration. Of course the KoboAdmin tools are not finished yet and I actively update this project. But the main idea is now clear: automate administration routines to avoid possible bugs and critical errors.
The main motivation of making server updates is obvious: the mobile client can occasionally became incompatible with the old frozen server version. This would mean death for the server with a lots of data and a wide client base, because migrate frozen DB to the new one can be too error prone for those who is not a direct developer of the KoboToolpack.
So let’s track somewhere the discussion about how an admin shell react onto the recent server changes. If there happen any migration task – the correct recipe shell appear and shell be well tested. I suggest the KoboAdminTools project because I have not found yet any other place dedicated to this server administration.
Updates of the KoboDocker I’m planning to track automatically and promise you to react as soon as possible.