J’ai un adapteur qui lit apartir d’un fichier CSV, ligne par ligne, et qui remplit les occurences dans une table.
L’adapteur ne génére aucun erreur. Dans le fichier log, c’est marqué comme si l’adapteur passe et enregistre toutes les occurences mais dans la table concerné je trouves pas le totalité des objets.
En investiguant, je trouves que le row id n’est pas correctement autoincrémenté et qu’il est dupliqué pour certaines objets.
Sauriez-vous l’origine du probléme ?
Merci pour votre support,
Akram Wali
Sans le code de votre adapter on ne peut pas deviner quel est le pb.
Mais clairement ce n’est pas un pb Simplicité mais forcément la manière dont votre code est écrit…
Celui ci reproduit le mode “upsert” des imports XML/JSON/CSV standards
PS: dans Simplicité il est théoriquement impossible d’avoir des doublons de row ID en base (le row ID étant géré par des séquences), je soupçonne donc que vous faites des insertions directes en base avec une génération “manuelle” du row ID inséré, ce qui est un anti-pattern absolu avec Simplicité, mais je me trompe peut être (sans votre code je ne peux pas le savoir).
Attention je vois que vous utilisez une version ancienne (4.0.P24), l’exemple de code que je vous ai indiqué ne marchera pas, il faudra donc commencer par vous mettre à jour sur la branche 4.0.
OK tel que c’est écrit (utilisation des APIs Java d’objet métier = search et create si le record n’existe pas) il est théoriquement impossible de générer des doublons de row ID techniques.
Par contre je ne sais pas dire si vous ne générez pas des doublons fonctionnels (ça, ça dépend du paramétrage de votre objet)
Utiliser une version aussi ancienne n’est pas une bonne chose. Envoyez moi le health check complet pour que je regarde de plus près les correctifs apportés depuis la révision que vous utilisez. Je me rappelle qu’en 4.0.P25, il y a eu une correction sur un pb subtil avec les séquences PostgreSQL, si vous êtes sur PostgreSQL c’est peut être une piste s’il y a réellement des doublons de row ID.
En tout état de cause notre support est conditionné par le fait d’être raisonnablement à jour, ce n’est pas le cas ici.
Ci dessous le health check complet
[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-10-14 23:22 (revision 3c63448f648587d9a89ec04d597946d26e4f7937)
Encoding=UTF-8
EndpointIP=172.17.0.7
EndpointURL=http://1ad3658f9cb5:8080
TimeZone=Europe/Paris
SystemDate=2021-02-19 14:28:06
[Application]
ApplicationVersion=0.1 dev
ContextPath=
ContextURL=https://int.rpw.dev.aws.renault.com
ActiveSessions=6
TotalUsers=9
EnabledUsers=8
LastLoginDate=
[JavaVM]
Version=14.0.2
Vendor=Red Hat, Inc.
VMName=OpenJDK 64-Bit Server VM
VMVersion=14.0.2+12
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.11 2019 05 30
HeapFree=413184
HeapSize=524288
HeapMaxSize=1835008
TotalFreeSize=1723904
OK vous êtes en retard d’au moins 218 commits, y compris quelques corrections critiques notamment pour PostgreSQL
Bref commencez par vous mettre à jour.
Vous comprenez qu’il est impossible d’assurer du support sur une révision aussi ancienne vs la révision actuelle. Vu le nombre de commits en question on parle peut être d’un pb corrigé depuis longtemps.
Et de toute façon même s’il s’agit d’un pb qui existe encore, il ne pourra être corrigé que sur le head de la version 4.0 maintenance, donc vous devrez de toute façon vous mettre à jour.
ATTENTION si vous utilisez une image Docker assurez vous que vous utilisez bien le tag 4.0-latest (avec le numéro de version 4.0 en prefix) car si vous utilisez le tag latest (sans le numéro de version en préfix) ce tag a désormais basculé sur la version 5. Cf. les annonces sur ce forum à ce sujet, or si vous basculez en version 5 vous ne pourrez plus revenir en 4.0. La version 5 induit quelques compatibility breaking changes, une migration 4.0 vers 5 n’est donc pas anodine.
[JavaVM]
Version=14.0.2
Vendor=Red Hat, Inc.
VMName=OpenJDK 64-Bit Server VM
VMVersion=14.0.2+12
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=367971
HeapSize=524288
HeapMaxSize=1835008
TotalFreeSize=1678691
Le passage sur une version à jour ne corrigera pas les éventuels doublons générés précédement.
Quand vous dites “le problème persiste” vous êtes sûr que les pbs en question correspondent bien à un traitement effectué sur une version à jour ?
Je pose la question car, pour le coup, sur une 4.0 ou 5 à jour il n’y a normalement vraiment plus aucune chance d’avoir des doublons de row ID sur PostgreSQL.
En tout cas si vous utilisez bien les séquences => vérifiez que la valeur du paramètre système USE_POSTGRESQL_SEQUENCE est bien à yes (et qu’aucune surcharge statique ou dynamique vient le passer à no)