Merge en masse

Request description

Bonjour,

Je souhaiterais savoir s’il est possible de réaliser des opérations de merge en masse dans Simplicité sans passer par l’IHM

L’objectif serait de pouvoir automatiser ou exécuter ces traitements de manière plus efficace (via script, API, ou tout autre mécanisme disponible côté plateforme)

Pouvez-vous me confirmer si cette fonctionnalité existe nativement, ou s’il existe une approche recommandée pour ce type de besoin ?

Je vous remercie par avance pour votre retour

Technical information

Instance /health
[Platform]
Status=OK
Version=6.2.20
BuiltOn=2026-01-02 22:59
Git=6.2/247648a272030a5c6026aa4c146866d268d8b124
Encoding=UTF-8
EndpointIP=100.88.68.191
EndpointURL=http://rfs-70537-api-7f474487cc-mzzv6:8080
TimeZone=Europe/Paris
SystemDate=2026-04-21 11:15:53

[Application]
ApplicationVersion=0.16 dev
ContextPath=
ContextURL=https://rfs-70537-api.ext.gke2.int.gcp.renault.com
ActiveSessions=0
LastLoginDate=2026-04-21 11:15:00

[Server]
ServerActiveSessions=0
ServerSessionTimeout=30
CronStarted=true

[JavaVM]
HeapFree=202028
HeapSize=342016
HeapMaxSize=1290240
TotalFreeSize=1150252

[Cache]
ObjectCache=64
ObjectCacheMax=10000
ObjectCacheRatio=0
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0
APIGrantCache=2
APIGrantCacheMax=1000
APIGrantRatio=0

[Healthcheck]
Date=2026-04-21 11:15:53
ElapsedTime=8

Bonjour,

Le merge consiste à :

  • mettre à jour un record “master” avec certains champs des autres records qui seront supprimés ensuite
  • lui associer les liens 0,n des autres objets (mettre à jour les FK ou supprimer certains liens)
  • et supprimer les doublons

Cela peut être fait spécifiquement par code.

Une action de merge existe en standard en front pour fusionner jusqu’à 5 records.
Cette action appelle, via les couche Ajax JSON, la méthode ObjectDB.merge :

/**
 * Merge all records and links
 * @param ids Row IDs to merge in the current object
 * @param map Id indexes per field (keep current value when absent) and per link (removed if absent, moved if present)
 * @param linkIds optional explicit IDs per link and index to preserve
 * @return Error codes or null
 */
public List<String> merge(List<String> ids, Map<String, List<Integer>> map, JSONObject linkIds)
  • ids : liste des row_id à fusionner, le premier étant le master qui sera gardé
  • map décrit ce qu’il faut garder par champ et par relation
  • et optionnellement chaque linkIds des records liés à garder

Vous pouvez activer la fonctionnalité de merge sur votre objet

  • surcharger cette méthode pour regarder ce qu’elle reçoit du front
  • pour reproduire cet appel dans votre code spécifique

Bonjour,

Merci pour votre retour.

J’en profite pour vous partager un autre comportement que nous avons remarqué lors des merges

Lorsque nous réalisons le merge d’un élément vers un autre, si l’élément rattaché contient plus de 20 sous-éléments (par exemple un site avec 25 adresses attachées), nous constatons qu’au-delà de 20 éléments, certaines données semblent ne pas être reprises correctement lors du merge.

Nous nous retrouvons alors avec des éléments orphelins (dans notre cas des adresses), comme s’il y avait une forme de pagination ou de limite appliquée pendant le traitement du merge.

Avez-vous déjà rencontré ce comportement, ou existe-t-il une configuration/limitation connue à ce sujet ?

Merci d’avance pour votre aide.

Cordialement,

Bonjour,
Merci pour ton analyse et ton retour.

Oui le merge utilise la pagination pour ne pas tout monter en mémoire.
Après vérification, l’algo est bien thread-safe et synchronisé sur l’instance dédiée au merge de chaque lien : mergepanel_ajax_<child>_<fk>

Par contre en 6.2 la pagination du merge contient des mises à jour vers l’objet master, du coup la page suivante est potentiellement fausse car tout est décalé.

Ca a déjà été corrigé en 6.3 avec l’arrivée d’une fonction “page-safe” avec fonction lambda
public final void search(final BiFunction<Integer, Integer, Boolean> onRow)
qui pagine d’abord pour lister les Id à modifier, puis appelle la fonction lambda dans le bon ordre des Ids trouvés = car la fonction pouvait potentiellement modifier le résultat de la recherche paginée elle-même (comme dans un merge).

La 6.2 ne sera plus corrigée, il vous faut passer en 6.3.