Problème d'archivage dans l'historique des données linky depuis V4.0.40

Bonjour à tous et à toutes

depuis le passage en V4.40 … qui d apres le log a fait quelque modif sur les index de la base …

j ai tous les soir lors de l archivage a 5h00 la nuit le message suivant :

[Erreur] history::archive() : [MySQL] Error code : 23000 (1062). Duplicate entry ‹ 3071-2018-01-01 00:00:00 › for key ‹ unique › : INSERT INTO historyArch(cmd_id,datetime,value) SELECT cmd_id,datetime,avg(CAST(value AS DECIMAL(12,2))) as value
FROM history
WHERE datetime <= :archiveTime
AND cmd_id=:cmd_id
AND value IS NOT NULL
GROUP BY UNIX_TIMESTAMP(datetime) DIV :archivePackage

l id 3071 c est les relevé annuel de linky
j ai même pb sur annuel, mensuel et journalier si je les supprime de la base l archivage tourne 1 fois …et plante au second lancement …

en première analyse je pense que le pluggin recupère les memes données tous les jours et que si il essaye de les archiver plusieurs fois ca produit ce type d erreur

J ai commencé à chercher mais j avoue pas encore avoir de piste pour la correction facile (sauf désactiver l archivage ce que j ai fait mais qui est pas satisfaisant …)

suis je le seul a avoir constaté le pb et un ou une de vou sa t il une piste …

merci d avance

J’ai eu un message d’erreur équivalent cette nuit à 5h du mat :

Erreur sur history::archive() : [MySQL] Error code : 23000 (1062). Duplicate entry '808-2017-01-01 00:00:00' for key 'unique' : INSERT INTO historyArch(cmd_id,`datetime`,value) SELECT cmd_id,`datetime`,avg(CAST(value AS DECIMAL(12,2))) as value FROM history WHERE `datetime` 

merci et c est comme moi suite au passage en V4.40 ?

Oui, et quand je vais dans les équipements du plugin en question j’ai juste le menu du haut, et lorsque je fais un F5, j’ai les équipements qui s’affiche, mais les chaines de caractères ne s’affichent pas correctement. Et lorsque je clique sur mon équipement, ça ne fonctionne pas.

moi pour le supprimer en attendantj ai ete sur la commande dans la partie configuration j ai décoché historique mais c est pas une bonne solution …

en V4.40 il y a eu plein de modif d index
Update system into : 4.0.39…OK
Check jeedom consistency…
[START CONSISTENCY]
[START CHECK AND FIX DB]
Fix : ALTER TABLE cmd DROP INDEX unique;
Fix : ALTER TABLE cmd DROP INDEX isHistorized;
Fix : ALTER TABLE cmd DROP INDEX type;
Fix : ALTER TABLE cmd DROP INDEX name;
Fix : ALTER TABLE cmd DROP INDEX subtype;
Fix : ALTER TABLE cmd DROP INDEX eqLogic_id;
Fix : ALTER TABLE cmd DROP INDEX value;
Fix : ALTER TABLE cmd DROP INDEX order;
Fix : ALTER TABLE cmd DROP INDEX logicalID;
Fix : ALTER TABLE cmd DROP INDEX logicalId_eqLogicID;

je pense que c est la dedant qu il y a maintenant un index unique et que du coup l insert plante …

je vais regarder le code du pluggin linky mais pas avant ce soir et pas sur qu il y est une sol evidente …

La réponse est la :

merci pour l info étrange que ca apparaisse apres passage en 4.40 ?? mais bon

par contre j ai relu 3 fois les explication de Loic et honte a moi j ai pas compris ou il avait remplacer le Insert par un remplace ???dans le module Core.class.history.class.php. Parceque j ai le pb et j ai pas de insert dans ce module ???
Mais j ai surement rien compris désolé

excuset j ai ete moi aussi trop vite en fait regression en 4.40 les INSERT sont revenue dans les version precedente on avait bien des REPLACE je remet l ancien module et j imagine que ca va rentrer dans l ordre ?

Même pas sur la ligne 215 ?
Attention, Loic n’a pas fait que remplacer INSERT par REPLACE

Si module est égal à fichier, je ne m’aventurerais pas sur ce genre de modif.
Reprendre un fichier d’une ancienne version et l’appliquer dans une autre version ne peut que créer des problèmes.

ok je restaure en 4.38 et je teste sur ma machine de qualification …tu as raison prudence est mere de sureté[quote=« jpty, post:10, topic:17746, full:true »]

Si module est égal à fichier, je ne m’aventurerais pas sur ce genre de modif.
Reprendre un fichier d’une ancienne version et l’appliquer dans une autre version ne peut que créer des problèmes.
[/quote]

mais a qui signaler que les replace sont redevenus des insert entre 4.38 et 4.40

Le pb a été signalé à Loic là: La table history ne se vide plus
Il a fait la correction en 4.1 et il précise à la fin de sa réponse que

Si c’est valide alors ca passera en v4 aussi

Vous êtes sûr de n’avoir le pb que depuis la 4.0.40 ?
Je l’avais depuis environ le 10 janvier (27000 lignes dans la table history ) ainsi que des utilisateurs du plugin suivi-conso

moi j ai le message duplucate key depuis 2 jours ce qui correspond au passage en 4.40

et c est facile de verifier dans les sauvegardes quand les REPLACE SQL sont redevenus des IINSERT SQL je vais chercher ce soir

J’ai regardé dans un backup de la 4.0.38.
C’est très différent.
Loic a expliqué dans sa réponse pourquoi ça a été modifié:

Oui j ai vu le code a rien a voir …
mais je confirme que dans les backup 4.038 il n y a que des SQL REPLACE et a partir de 4.040 on plus que des SQL INSERT …

ca ressemble a une regression de code une erreur on a remis le vieux module ? je regarde dans les premiere version 4.0 que j ai

(je garde 3 mois de sauvegarde je suis un peu parano j avoue …)

Non, c’est une optimisation pour des pb de performance avec des plantages des box.

bon j ai pas avant le 10 janvier en 4.0.38 avant j etais en 3.3.39 et dans cette version le modulme est similaire a celui de 4.0.38 c est a dire que l on trouve des SQL REPLACE

Donc les Lignes SQL INSERT sont donc des nouveautés liée a la 4.0.40 …

a transmettre a Loic je pense je vais ouvrir un sujet sur ca dans le core qu en penses tu ?

Inutile de resignaler à Loic, il a déjà corrigé en 4.1 et remplacé INSERT par REPLACE et ajouté un try/catch pour que l’historisation se fasse quand mème.
Voir l’autre discussion.

rire oui mais en 4.0.40 ca va replanter puisqu il y a des INSERT ???

je pense plus correcte de le signaler car je vais pas etre le seul a mon avis ca touche le plugin linky mais peut etre d autre