Sqlite et dolibarr?

Bonjour à toutes et tous,
j’ai une question « base de données » … est-ce que vous avez déjà testé dolibarr avec sqlite ? ça semble idiot mais pas tant que ça quand on se pose dans la direction tests d’intégration continue avec une vraie bdd et de vraies données.

lancer un docker avec un mysql c’est bien mais dans une optique « frugale » (surtout avec le prix de la ram qui monte) je me pose la question de faire des installations ultra légères à base de sqlite (sans docker donc, merci @SimBaIT :wink: )…

merci d’avance pour vos retours
Éric

3 « J'aime »

Cadeau de noël pour les dev ?

GitHub - rycks/dolibarr-integration-sqlite: Pre-setup version of dolibarr with sqlite - designed for continuous integration not for production

En résumé:

git clone https://github.com/rycks/dolibarr-integration-sqlite.git
cd dolibarr-integration-sqlite
chmod +x run.sh
./run.sh

puis ouvrez http://localhost:8080/ vous avez un dolibarr 18.0 préinstallé avec une base sqlite, login admin mot de passe adminadmin

je continue pour voir si je peux réaliser des tests d’intégration de mes modules avec des vraies données dolibarr, c’est grosso-modo l’étape suivante de phpstan

2 « J'aime »

(re)
pardon je squatte le forum un peu comme un carnet de bord.

Je viens de faire le fichier zip de dolibarr « autonome » : il pèse 70 Mo avec une mini base sqlite et uniquement 2 langues embarquées pour pouvoir déployer ce zip dans les outils d’intégration continue …

Avec un peu de chance comme le zip ne changera pas trop il restera en cache des outils d’intégration continue et on pourra avoir des perfs pas trop moches !

1 « J'aime »

je pensais depuis peu à lancer ma moulinette d’import de data via les api avec postgres, mais le faire avec sqllite (et aussi SQL SERVER), serait un truc sympa aussi

4h plus tard à force de transpirer …

Tout ça pour …

Un score de 5% et 21% de couverture du code … hében il en reste du boulot !!!

Documentation si ça intéresse d’autres développeurs:

1 « J'aime »

Bonjour,

Juste une note en passant : j’ai noté « solution » mais le fil est toujours ouvert pour échanger sur ce sujet en cette nouvelle année :slight_smile:

Bonjour @erics,

Avant tout bonne et heureuse année

En effet j’ai du mal à comprendre la solution, en quoi des tests unitaires pour un module ont un lien avec un docker Dolibarr avec sqlite?

Car projet me semble très intéressant

@SimBaIT il n’y a pas de docker dans cette histoire normalement, enfin, s’il y a qqpart un truc qui parle de docker il faut me le dire c’est que j’ai fait une erreur dans mes copier/coller et nombreux tests car oui j’ai fait un ‹ passage › par docker pour avancer de manière itérative :slight_smile:

En fait il faut voir les tests à deux niveaux:

  1. tests unitaires
  2. tests d’intégration

tests unitaires

Les tests unitaires sont ceux qui permettent de valider qu’une fonction fait bien ce qu’il faut, par exemple si j’ai cette fonction


function somme($a,$b) {
  return $a+$b;
}

les tests unitaires vont tenter de faire 1+1 et vérifier que ça fait bien 2 … et si on améliore on peut ajouter un test 0.1+0.2 pour vérifier que ça fait 0.3 car le test précédent n’est que sur des entiers sans décimales et ainsi de suite, j’espère que c’est assez clair …

tests d’intégration

ceux là sont plus pêchus : ils demandent à avoir un dolibarr utilisable, par exemple si je veux pouvoir tester l’ajout de lignes dans un objet facture pour voir le résultat des arrondis des totaux et les résultats des calculs de tva … je donne cet exemple car c’est exactement ce qui m’a motivé à passer tant de temps sur ce sujet : pour le module de facture électronique ! il faut s’assurer que le résultat affiché dans le pdf est le même que celui calculé par les outils qui produisent le xml (car oui les vérifications côté points d’accès « refont » les calculs inverses et il faut que ça tombe juste)

et là … comment faire pour utiliser les objets et fonctions dolibarr ? il faut un dolibarr

ok s’il faut un dolibarr il faut aussi un … mysql … et là ça commence à devenir sacrément lourdingue, la « solution » est généralement … docker qui permet d’avoir tout d’un coup mais ça pèse lourd : l’image dolibarr sur docker hub pèse 296Mo et surtout sur nos « machines » ça demande de la ram, du cpu, de l’énergie etc.

je me suis demandé s’il serait possible d’avoir une version légère avec un sqlite au lieu d’un mysql pour pouvoir gagner en temps, en poids, en impact global

bien sûr l’idée est que lorsqu’on a passé tous les tests avec sqlite on puisse ensuite lancer un vrai test avec un dolibarr+mysql (docker) mais comme dans la majorité des cas la version « sqlite » suffit pour débusquer les problèmes d’intégration ça évite de lancer des centaines de fois docker+mysql …

est-ce que c’est plus clair ?

1 « J'aime »

Et le tout premier message de ce sujet ?

1 « J'aime »

@SimBaIT hahaha oui mais il faut bien lire

« lancer un docker avec un mysql c’est bien mais dans une optique « frugale » (surtout avec le prix de la ram qui monte) je me pose la question de faire des installations ultra légères à base de sqlite … »

est-ce que avec ma dernière explication ça éclaire mieux que l’objectif visé était sans docker ? je viens d’éditer le message initial en ce sens !

:slight_smile:

Et le tout premier message de ce sujet ?

:sob:

Un docker avec sqlite pour des tests rapide ca me tentais bien

Ha, détaille le besoin, ça m’intéresse

Éric

A priori dolibarr n’a pas la capacité de se connecter à une base sqllite par défaut

du coup je me demande bien comment tu as fait ton affaire (une modification du core?)

Ha c’est que t’a pas cherché très loin: il y a des traces de sqlite dans le core (tips: find | grep sqlite), incomplet certes mais il existe. J’ajoute au fil de l’eau ce que je peux comme je peux et j’en parlerais probablement en « off » aussi lors du prochain devcamp autour d’un café ou d’une mousse pour savoir si ça intéresse ou pas d’autres développeurs qui ne fréquentent pas le forum et le cas échéant je proposerais de verser dans le coeur les améliorations en question avec un « truc » pour que ça ne soit surtout pas utilisable en production.

Pour moi c’est exactement comme ma proposition de php-scoper, j’en parle sur le forum, j’en parle quand je rencontre des développeurs, l’idée suit son cours (ou pas peu importe, c’est une forme de contribution ce qui m’importe étant d’échanger sur des points de vues et des idées).

Pour en revenir sur sqlite et dolibarr, si tu veux plus de détails il suffit de cloner GitHub - rycks/dolibarr-integration-sqlite: Pre-setup version of dolibarr with sqlite - designed for continuous integration not for production et de lire le code source, un diff entre la version 18 officielle et la 18 de ce dépôt te donnera toutes les réponses :slight_smile: attention il n’y a pas que sqlite que je m’autorise à modifier au passage … c’est une des forces de pouvoir faire des forks : on teste un truc.

Et pourquoi pas en production ? On peut même faire du sqlite distribué (soit tout le contraire du but de sqlite au départ) :winking_face_with_tongue:

Juste une idée qui m’est venue en lissant le sujet
Un beosin de tester une nouvelle version ou un plugin
Un simple docker run ou docker compose et c’est fonctionnel

1 « J'aime »

Bonjour,
Si jamais ça vous tente la dernière version de la doc est disponible pour relecture / commentaires / etc ici : TESTING - MarginaliaMD

Je viens d’appliquer cette recette pour assurer la couverture de code et des tests fonctionnels pour plusieurs modules de cap-rel, le gain qualitatif est vraiment important même si ça demande beaucoup de temps … cette doc est disponible et l’outil qui fait tourner md.cap-rel.fr permet de collecter des remarques / contributions ciblées sous une autre forme que le forum, à vous de voir ce que vous préférez.

Éric

Hello,

comment fais-tu pour tester les contraintes de clés étrangères avec SQLite ?

sqlite ne sait pas gérer ça donc « je » ne risque pas de tester cette partie c’est une limite bien réelle, c’est pour ça que j’ai clairement dit « pas en prod »

on se situe « en chemin » entre un test d’intégration « total » avec mysql chargé (coucou docker pour avoir un truc reproductible) qui pompe un max de ressources et « pas de tests d’intégration »

pour aller jusqu’au bout en fait j’ai en local les tests d’intégration sqlite, sur le serveur d’intégration sqlite aussi car j’ai pas les moyens de payer des Go++ de ram/cpu mais j’ai un autre serveur d’intégration (pas continue) que je peux solliciter à l’occase dans le garage qui lui fait tourner du docker et … donc lance les tests dans une situation plus réelle

la version sqlite permet de débusquer une énorme quantité de problèmes à côté desquels je passais jusqu’à présent (exemple on créé une facture, on lance la génération du pdf → « mon » module capture le trigger pour empaqueter le pdf dans du xml pour peppol ou ajoute le xml dans le pdf pour facturx) … avant je m’arrêtais aux tests unitaires, à phpstan et c’est tout

maintenant je peux tester le cas où le contact facturation de la facture n’a pas d’adresse et donc la facture générée n’est pas conforme à la norme peppol … et ça … ça passe par générer un vrai pdf, puis générer un vrai xml puis ouvrir le xml avec un analyseur et vérifier la conformité du document produit, on est loin de la vérification de si la fonction somme fait bien a+b :slight_smile:

1 « J'aime »