Rebuilding docker wipes out existing data in database

[F117aDriver]

Describe the bug My setup is running in docker on an Unraid system. When the hortusfox container is updated, the database initialization procedure seems to run, deleting and recreating the database tables and wiping out all current data. The database is in a separate mariadb docker container.

To Reproduce Steps to reproduce the behavior:

1. Install docker container
2. Save some locations, plants
3. Rebuild the image/container and point it at the existing database
4. POOF, all saved data is gone.

Expected behavior Initialization should check if data exists and not overwrite it.

Software: HortusFox v3.5 PHP Version: 8.3.0 MySQL Version: 10.11.8-MariaDB

Desktop (please complete the following information):

• OS: Linux Mint
• Browser: Brave (based on chrome)
• Version: Of which? Mint 21.3, Brave 1.70.123

[Appoxo]

I am using the docker container from the repo ghcr.io/danielbrendel/hortusfox-web and the dockerhub mariaDB container mariadb:11.3
At least my container upgrade didnt nuke my database
My browser is firefox v131 on Win11

[danielbrendel]

Hi,

I am sorry for the inconvenience caused.

Are all tables re-created or just a few? If the first one is the case then it's likely because the migration.list wasn't taken into account for the migration process. The migration.list (located in /app/migrations) is a very crucial file that is used to determine what tables need to be created when using the "listly" migration type and it is normally bound to a volume.

When you say that you are using a "separate mariadb docker container": Does that mean you changed anything in the docker-compose.yml? Or the docker-compose.sh?

Message ID: @.***>

[F117aDriver]

No inconvenience! I love that you've created this project!

• Table Impact: Every table in the hortusfox database is zero length after "auto update" by Unraid/Docker
• Migrations.list Impact: Unraid template for hortusfox creates a volume to persist config files etc used by the docker. I think this might be the source of the problem (whoever created the unraid docker template has it wrong). There are only two volumes set up to persist any data: /var/www/html/public/img, and /var/www/html/app/logs. If this Migrations.list file needs to persist, then the template is not set up to do that...
• MariaDB Use: I used a template for Unraid. Unraid has a mechanism to install/start/maintain docker containers running. It's web interface has fields to set environment variables, and it generates its own docker run command. Whomever created it for hortusfox needs to look at the docker compose, determine what the equivalent run command line should look like, and generate the web interface field to duplicate it. So essentially I'm utilizing the DB_* environment variables to set the DB_HOST, PORT, USERNAME etc, all of which point to another docker container running a MariaDB. I have Unraid set up to autoupdate my running containers and HortusFox was one of them (I've since disabled this autoupdate so I can find out what's happening).

[F117aDriver]

I just confirmed that with this template, the migrations.list file is not bound to any volume so it doesn't persist. If this file is what prompts the system to re-create the tables then this is the source of the problem. I need to figure out how to persist that file in an "Unraid manner"...

[F117aDriver]

I reviewed the docker_compose.yml file and compared to the template on Unraid's docker repo and I think (I'm no way a docker expert) that the template is missing three volume mappings and I suspect the migrations one is causing my DB to get wiped out. I've add the mappings to my setup and we'll see how it goes and in the meantime, I may try to determine how to update the template on Unraid's repo.

This is not a bug with hortusfox. It's a malformed docker template in the Unraid docker repo.

• Thanks for the support!