bug : la base de donné sqlite dans le volume n'est pas la bonne (en tout cas en mode production)

[PhilippeAccorsi]

Actuellement

Dans le docker-compose.yml il y a le montage suivant :

    volumes:
      - ./PV/mercator/db.sqlite/:/var/www/mercator/sql/db.sqlite

Mais en fait cette db est vide, même après la création de contenu. Si on souhaite réutiliser la db sur une autre machine (mon cas aujourd'hui), et bien on a aucune data de disponible (plus de compte users non plus). Pourtant le readme indique bien de créer ce fichier db.sqlite.

Après recherche dans le container directement, j'ai découvert que la bdd utilisé est ici /var/www/mercator/database/ et est nommé database.sqlite.

Actuellement, cette db n'est pas dans un volume, donc à la destruction du container on perd tout le travail réalisé.

Côté config, je suis en mode APP_ENV=production avec DB_CONNECTION=sqlite.

Attendu

• un volume docker est bien présent pour stocker les données persistante
• si en production la bdd est différente de celle utilisé pour le développement, il serait intéressant d'avoir une information dans le readme
  • Bonus : avoir la possibilité de garder la même db entre dev et prod (pour repartir avec les même données)

[PhilippeAccorsi]

Je me demande s'il n'y a pas un souci en fait dans le docker-compose.yml car on vois que les 2 lignes n'ont pas la même syntaxe pour le volume

      - ./PV/mercator/db.sqlite/:/var/www/mercator/sql/db.sqlite
      - ./env/mercator.env:/var/www/mercator/.env

La première indique ./PV/mercator/db.sqlite/ et la seconde ./env/mercator.env. J'imagine que le / est en trop après le nom du fichier de db, et c'est peut-être pour cela que le fichier database.sql est utilisé dans le container (genre valeur par défaut du code).

[PhilippeAccorsi]

En supprimant mon container, puis en retirant le / dans la définition du volume et en redémarrant, je me retrouve tjrs dans la situation où la bdd est "vide".

Si je me connecte dans le container, j'ai les informations suivante :

82599a027fb5:/var/www/mercator/database$ ls -l
total 1560
-rw-r--r--    1 mercator www        1568768 Oct 29 00:56 database.sqlite
drwxr-xr-x    1 mercator www           4096 Oct 25 11:58 factories
drwxr-xr-x    1 mercator www           4096 Oct 25 11:59 migrations
drwxr-xr-x    1 mercator www           4096 Oct 25 11:58 schema
drwxr-xr-x    1 mercator www          12288 Oct 25 11:58 seeders
82599a027fb5:/var/www/mercator/database$ cd ../
82599a027fb5:/var/www/mercator$ grep -arw "db.sqlite" .
./.gitignore:docker-compose/PV/mercator/db.sqlite
./.env.sqlite:DB_DATABASE=/var/www/mercator/sql/db.sqlite

On remarque qu'un nouveau fichier database.sqlite à été créé au démarrage.

La commande précédente à mis en évidence le fait qu'il y a un fichier .env.sqlite mais ce n'est pas le fichier sur lequel on a le montage du volume dans le docker-compose.yml
On remarque aussi qu'il y a d'autre fichier .env...

82599a027fb5:/var/www/mercator$ cat .env
.env          .env.ci       .env.example  .env.sqlite

Le souci est peut-être que le sqlite n'est pas "possible" en mode production, ou un truc du style ?

La solution que j'ai trouvé pour avoir mes données de prod dans du sqlite :

• ajouter le volume - ./PV/mercator/database.sqlite:/var/www/mercator/database/database.sqlite dans le docker-compose.yml
• démarrer normalement

Avec la récupération du fichier qui était dans le container, la modification des droits et l'ajout du volume, je peux correctement réutiliser les données que j'avais saisi précédemment et prévoir de sauvegarder la bonne db :)