lors du déploiement de la 5.1.13 ce matin sur un environnement 5.1.10, j’ai relevé les erreurs / warning suivants:
Erreur relative à la modification de libs system (j’imagine que c’est lié à l’ajout de deux jars dans notre Dockerfile)
2021-11-22 12:10:48,136|SIMPLICITE|ERROR|Checksum verification failed on [libs] directory ([02eeade8c2b4df13753817e264404243] vs [56f8d0a5e595399fb351ad5e44b1bf8b]), some core system files have been altered or files have been removed or added. This may have unpredictable effects!
2021-11-22 12:14:01,608|SIMPLICITE|WARN|Database patch SQL request = delete from m_grant g where not exists (select 1 from m_function f where g.grt_function_id = f.row_id) / warning = You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'g where not exists (select 1 from m_function f where g.grt_function_id = f.row_i' at line 1
2021-11-22 12:14:01,599|SIMPLICITE|INFO|Importing database patch file /usr/local/tomcat/webapps/ROOT/WEB-INF/patches/V5/P01/cleandb_mysql.sql
oui surement si les JAR sont ajoutés avant le checksum
Ce delete cherche à supprimer les m_grant orphelin / sans fonction.
Bizarre comme requête, perso j’aurai fait un “not in” dans un delete, car la jointure n’a justement aucun sens (ou alors via un outer join qui serait null).
delete from m_grant where grt_function_id not in (select f.row_id from m_function f)
on a ajouté ce contrôle justement pour pouvoir détecter plus facilement les cas où les gens qui nous remontent des comportements bizarres ont ajouté ou modifié des composants du socle et ont oublié de le signaler
ATTENTION : Je vois ici que le libs ajoutées sont des libs “netty”, or on en embarque déjà quelques unes (une douzaine) mais pas dans cette version (cf. Simplicite Platform – Project Dependencies) = en Simplicité 5.1 on est sur des 4.1.49.Final en release et en 4.1.59.Final en beta et alpha => du coup le message “unpredictable effects” est sans doute légitime avec ces 2 libs en version 4.1.56.Final qui ne matche pas celle des autres libs “netty” embarquées. Quand on ajoute de libs additionnelles il faut impérativement s’assurer de leur compatibilité avec les autres libs déjà présentes = nous consulter sur ce point. En l’occurrence il me semblerait mieux qu’on ajoute en standard ces 2 libs “netty” en plus de celles déjà embarquées
En fait, elles sont en test de notre côté et leur usage est limité à une classe bien identifiée en bout de traitement (publication d’events en postXXX). Sauf si tu penses utile de les intégrer de manière cohérente dans l’image standard, ça nous évitera le spécifique dans le Dockerfile mais sinon, je peux tout simplement mettre à jour les versions que nous ajoutons (j’avoue que j’avais repris ces instructions de copie de l’intégration v4 précédente sans prendre le temps de revoir ces aspects de compatibilité ).
Merci, patch passé manuellement sur nos environnements de dev/test montés en 5.1.13.
ps: Nous avons a priori obtenu le GO de tous nos métiers → nous monterons l’environnement de production BCSI en 5.1.13 lundi prochain (29/11). C’est notre dernier environnement encore en 4.0.P25.
).