Notes de version
Cette page présente les évolutions fonctionnelles et corrections d’anomalies. Pour plus d’informations sur la migration technique, merci de vous reporter à la page notes techniques de version et guide de migration.
Version 8.3.2
Fonctions unitaires
De nouvelles fonctions sont disponibles pour effectuer des traitements sur les données des DataBlocks et des sources de données des éléments de visualisations de HandleData.
Elles remplaceront les anciennes fonctions similaires lors de la prochaine version majeure (9.0).
Les nouvelles fonctions sur les constantes de type dates disponibles doivent être utilisées à la place des fonctions dépréciées.
Version 8.3.0
Evolutions dans la gestion des dates
Une évolution globale de la gestion des Dates (TimeStamp) a été réalisée.
Elle entraîne différentes modifications dans les interfaces et les fonctionnalités de GenericsData et HandleData.
L’ensemble des informations sur la manipulation des Dates dans DataChain est disponible dans le menu Opérations sur les données Dates.
Affichage des données de type Date (TimeStamp)
Afin de simplifier la lecture et la manipulation des Dates sur toute la chaîne de valeurs, elles sont désormais affichées par défaut au format ISO 8601 simplifié.
Le fuseau horaire dépend des paramètres de votre instance DataChain (UTC par défaut), contactez un administrateur DataChain en cas de doute.
Au survol, les Dates s’affichent toujours au format ISO 8601 complet et en UTC, peu importe le masque d’affichage appliqué.
-
ISO simplifié en UTC : 2023-09-01 13:42:24
-
ISO complet en UTC : 2032-09-01T13:42:24:000Z
En savoir plus sur l’affichage des données.
Masques, fuseaux horaires et langues
Les Masques utilisés pour la lecture, l’écriture ou l’affichage des Dates peuvent être modifiés et personnalisés.
Le masque d’affichage utilisé par défaut pour les Dates peut être modifié si besoin, à différents niveaux de la Chaîne de valeurs :
-
en sortie d’étape de DataBlock
-
dans les sources des visualisations de HandleData
Lors de l’ajout ou du paramétrage du Mapping d’une Entité Métier, ou lors d’une conversion vers le type Date en sortie d’étape d’un DataBlock, il est possible de définir un fuseau horaire et une langue en plus du masque de lecture.
Fonctions unitaires
2 nouvelles fonctions sont disponibles pour effectuer des traitements sur les données des DataBlocks et des sources de données des éléments de visualisations de HandleData et remplaceront 2 anciennes fonctions similaires lors de la prochaine version majeure (9.0).
Nouvelles fonctions
-
date.to_strz transforme une Date en Chaîne de caractères à partir d’un masque d’écriture, d’un fuseau et d’une langue
-
str.to_datez transforme une Chaîne de caractères en Date à partir d’un masque de lecture, d’un fuseau et d’une langue
Version 8.2.0
Evolutions
Modèles d’exports
Il est désormais possible de paramétrer des Modèles d’export réutilisables pour l’ensemble des Connecteurs disponibles dans DataChain (Local, Base de Données, Serveur distant).
Vous devez posséder la permission globale liée aux Modèles d’export pour pouvoir créer et utiliser des Modèles.
|
Par défaut cette nouvelle permission globale est inactive pour tous les groupes et les utilisateurs. Les Administrateurs DataChain peuvent modifier les permissions dans les pages de gestion des groupes et des utilisateurs. |
-
Utiliser un Modèle lors d’un export
Les Modèles d’export peuvent être chargés pour remplir automatiquement le formulaire d’export. -
Créer un Modèle
La gestion des Modèles est disponible depuis le menu "Divers".
Exports
L’interface d’export de DataBlock a été mis à jour suite à l’ajout des Modèles d’export.
De nouvelles options sont désormais disponibles.
Expositions
Ajout de variables sur les filtres : Il est désormais possible de limiter l’accès à l’exposition des données pour des utilisateurs ou des groupes à partir de nouvelles variables de filtres.
Formules
De nouvelles formules sont disponibles pour connaître la position d’un élément dans une liste.
[type].list.position(ListArg1, Arg2) : renvoie la position de la valeur *Arg2* contenue dans ListArg1
|
L’index est basé sur 1 La formule renvoie -1 si la valeur donnée est introuvable dans la liste |
Variantes de la formule
-
str.list.position(ListStrArg1, ListStrArg2) : recherche de valeur de type chaîne de caractères
Exemple : str.list.position(["moly","peter","marsh","carl"], "marsh")
renvoi 3 -
int.list.position(ListIntListArg1, IntArg2) : recherche de valeur de nombre entier
-
dec.list.position(ListDecListArg1, DecArg2) : recherche de valeur de type décimal
-
bigint.list.position(ListBigIntArg1, BigIntArg2) : recherche de valeur de type grand nombre entier
-
date.list.position(DateListArg1,DateArg2) : recherche de valeur de type date
Version 8.1.1
Version 8.1.0
Evolutions
-
Spécification de l’encodage des fichiers JSON, XML et CSV : il est désormais possible de préciser, au niveau des dépôts de type S3 MinIo, l’encodage des fichiers Json et xml.
-
Authentification sur le connecteur HTTP : ajout de paramétrage d’une authentification dans les dépôts de type HTTP
-
Changement de l’algorithme de hachage : l’algorithme de hachage utilisé dans la formule str.encrypt est sha256. Les versions précédentes utilisaient l’algorithme MD5.
-
Serveur d’authentification : passage à la version 21.1 de Keycloak.
-
Connecteur Power BI : Un connecteur DataChain est désormais disponible en option dans PowerBI. Il permet de consommer directement les Datablocks de DataChain exposés depuis l’interface de PowerBI.
-
Documentation La documentation Datachain est désormais disponible en ligne à l’adresse : https://docs.adobisdc.fr. Les liens dans les applications utilisent ce nouveau site. Cette nouvelle documentation nous permet de mettre à disposition un module de recherche documentaire, ainsi qu’une première version en anglais (tous les modules ne sont pas encore traduits et le seront ultérieurement).
Autres changements
-
Correction d’une anomalie de lecture des fichiers basés sur les connecteurs S3/MinIo.
-
La lecture des très gros fichiers Excel a été optimisée. Il ne devrait plus y avoir de limite.
-
Diverses corrections et améliorations
-
Gestion du motif dans les dépôts S3
-
Optimisation des websockets des jobs pour les requêtes portant sur de gros volumes
-
Sécurité : Activation de l’authentification PKCE https://ordina-jworks.github.io/security/2019/08/22/Securing-Web-Applications-With-Keycloak.html
-
Augmentation de la sécurité des mots de passe
-
Correction d’un dysfonctionnement lors de la suppression des formules dans les étapes des Datablocks
-
Version 8.0.0
Evolutions
La version 8 apporte un certain nombre de nouveautés, permettant notamment d’améliorer de manière significative les performances de l’application.
Modification de l’architecture de déploiement
De manière standard, l’architecture 7.0 est la suivante :
Un composant Redis est désormais intégré dans la stack Datachain, permettant d’assurer une communication asynchrone entre le composant backend et le composant spark.
Intégration du mode FAIR Spark
Dans une application Spark donnée (instance SparkContext), plusieurs tâches parallèles peuvent s’exécuter simultanément si elles ont été soumises à partir de threads distincts. Par "tâche", dans cette section, nous entendons une action Spark (par exemple, enregistrer, collecter) et toutes les tâches qui doivent être exécutées pour évaluer cette action. Le planificateur de Spark est entièrement thread-safe et prend en charge le cas d’utilisation qui correspond au fait de permettre aux applications de répondre à plusieurs requêtes (par exemple, des requêtes pour plusieurs utilisateurs).
Par défaut, le planificateur de Spark exécute les tâches en mode FIFO (cas de Datachain V7). Chaque tâche est divisée en « étapes » (par exemple, cartographier et réduire les phases), et la première tâche est prioritaire sur toutes les ressources disponibles tant que ses étapes ont des tâches à lancer, puis la deuxième tâche est prioritaire, etc. Si les tâches en tête de la file d’attente n’ont pas besoin d’utiliser tout le cluster, les travaux ultérieurs peuvent commencer à s’exécuter immédiatement, mais si les travaux en tête de file d’attente sont volumineux, les travaux ultérieurs peuvent être considérablement retardés.
Il est désormais possible de configurer un partage équitable entre les tâches dans la nouvelle version de Datachain, en activant le mode FAIR de spark. Dans le cadre d’un partage équitable, Spark attribue des tâches entre les travaux « à tour de rôle », de sorte que tous les travaux obtiennent une part à peu près égale des ressources du cluster. Cela signifie que les tâches courtes soumises pendant l’exécution d’une tâche longue peuvent commencer à recevoir des ressources immédiatement et obtenir toujours de bons temps de réponse, sans attendre la fin de la tâche longue. C’est ce mode qui est désormais activé par défaut dans Datachain.
Le mode de traitement des tâches est désormais le suivant :
Un job est soumis au backend, qui va le déposer dans une file d’attente Redis. Il est pris en charge par un contexte Spark, qui notifie au fur et à mesure de l’avancement du traitement (pris en charge, en traitement, en erreur, terminé, etc.). Redis, le système de gestion de file d’attente utilisé est aussi utilisé pour stocker les résultats d’exécution de job. Enfin, un système d’événement est aussi mis en place pour assurer la communication entre plusieurs backends déployés.
Les impacts sur la configuration et le déploiement sont les suivants (ne sont repris que les nouveaux éléments de configuration) : dans le fichier de déploiement docker-compose : Ajout du service Redis
dc_redis_cache:
image: redis:7.0-alpine
command: redis-server --loglevel warning
networks:
dc_network:
aliases:
- dc-redis
deploy:
mode: replicated
replicas: 1
placement:
constraints:
AJOUTER LES CONTRAINTES DE DÉPLOIEMENT (à déployer avec l’image backend)Dans la configuration backend (fichier backend.env), nouveau paramètre dc.app.notification.urls de valeur habituelle : redis://dc-redis:6379. Suppression des paramètres : dc.app.api.spark (remplacé par dc.app.context.url coté spark)
JAVA_OPTIONS=-Xms1024M -Xmx4g -Duser.home=/opt/dev/work
## Désormais inutile
## dc.app.api.spark=http://dc-spark1-1:8090,http://dc-spark1-2:8090,
## Simplifié ci-dessous
## dc.app.api.spark.security.user.name=backend,backend,backend,backend,backend,backend,backend,backend,backend
dc.app.api.spark.security.user.name=backend
## Simplifié ci-dessous
## dc.app.api.spark.security.user.password=aaaa,aaaa
dc.app.api.spark.security.user.password=aaaa
## Désormais inutile
## dc.api.spark.shared-file-system=true
## nouveau
# Configuration Redis
dc.app.notification.urls=redis://dc-redis:6379Dans la configuration spark (fichier spark.env) :
-
nouveau paramètre (identique au backend)
dc.app.notification.urls de valeur habituelle : redis://dc-redis:6379 -
nouveaux paramètres (pour plus d’information, voir documentation Datachain en ligne)
dc.app.job.manager.spark.thread.number=5 et dc.app.job.manager.other.thread.number=5 -
nouveaux paramètres (pour plus d’information, voir documentation Datachain en ligne)
dc.app.job.manager.spark.thread.number=5 et dc.app.job.manager.other.thread.number=5 -
nouveau paramètre : dc.app.context.url=http://dc-spark1:8090
-
suppression des paramètres (plus d’appels http de spark vers le backend)
dc.app.api.backend, spring.security.user.name, spring.security.user.password
## Désormais inutile
## dc.app.api.backend=http://dc-backend:8089
# Configuration du contexte Spark
dc.app.context.id=0
## NOUVEAU PARAMÈTRE
dc.app.context.name=context_0
## NOUVEAU PARAMÈTRE
dc.app.context.url=http://dc-spark1:8090
dc.app.spark.app-name=context1_1
# Configuration spark
## NOUVEAU PARAMÈTRE
dc.app.spark.scheduler.mode=FAIR
## NOUVEAU PARAMÈTRE
dc.app.job.manager.spark.thread.number=5
## NOUVEAU PARAMÈTRE
dc.app.job.manager.other.thread.number=3
## DEVENU INUTILE
# dc.keycloak.auth-server-url=http://dc-keycloak:8080/auth
## NOUVEAU PARAMÈTRE
# Configuration notifications
dc.app.notification.urls=redis://dc-redis:6379Sécurité
Des adaptations de sécurité ont été faites au niveau de l’application, parmi lesquelles :
-
certaines URLS pouvaient encore porter des tokens, ce n’est désormais plus le cas
-
les services backend et spark pouvaient être lancés en tant que root. Ce n’est désormais plus nativement le cas : les serveurs sont désormais déployés avec un utilisateur dc d’uid 38330 et un groupe Datachain avec un GID 38330. Attention, les droits sur les répertoires doivent être modifiés sur les arborescences HDFS (dans le cas d’un déploiement local ou cluster hadoop), pour donner les accès nécessaires à cet utilisateur qui n’a plus les privilèges root.
Autres évolutions
Tableaux de bord - HandleData
Zones de centrage
Lors du paramétrage d’une zone de centrage de type Date, il est désormais possible de paramétrer le type de date qui doit être utilisée lors de la saisie des valeurs.
Deux formats sont disponibles : date simple ou date avec heure
Paramétrage de la présence d’un Scroll.
Paramétrage de la présence d’un Scroll vertical ou horizontal pour chaque élément présent dans un Dashboard.
Publication de Dashboard
Il est désormais possible de supprimer une publication expirée.
Dans les versions précédentes, il existait une impossibilité de suppression d’un Dashboard si ce dernier contenait une publication expirée.
Désormais, afin de supprimer un Dashboard contenant une publication expirée, il faut, au préalable, supprimer à partir de l’onglet Publication du tableau de bord, la totalité des publications expirées ou archivées.
HandleData et Generics Data
*Gestion des formules *
Une meilleure prise en compte des valeurs de type null lors du traitement de certaines formules a été effectuée.
Les formules impactées sont en particulier les formules str.if, int.if, dec.if, bigint.if, str.compare.
Gestion des agrégations
Dans les versions précédentes, lors de la création d’une agrégation, la solution générait automatiquement un tri dans l’ordre des colonnes positionnées dans le regroupement.
Depuis la version DataChain 8.0, ce comportement n’existe plus.
Si besoin, l’utilisateur peut paramétrer ou non le tri qu’il souhaite.
Version 7.6.0
Evolutions
Suppression d’un Projet d’une Instance DataChain : il est désormais possible de supprimer totalement un Projet d’une instance DataChain.
La suppression d’un Projet se réalise depuis la carte d’un Projet.
Seuls les Administrateurs d’un Projet peuvent le supprimer.
Une connexion internet est nécessaire pour valider l’action de suppression d’un Projet.
Un mail contenant un Token de validation est envoyé sur l’adresse mail de la personne réalisant la suppression.
Un Projet consommé par un autre Projet ne peut pas être supprimé.
| À noter que la suppression d’un Projet est définitive. Il est conseillé de réaliser un export du Projet avant de réaliser sa suppression. |
- La suppression d’un Projet consiste en la suppression de tous les éléments d’un Projet à savoir
-
-
Publications
-
Tableaux de bord
-
La totalité des Visualisations (Média, Tableaux, Graphiques, TimeLine, Carte)
-
Sources des Visualisations
-
Datablocks et Expositions API des Datablocks (EndPoint et cache)
-
Entités Métier
-
Dépôts et les Extractions
-
Connecteurs
-
Fichiers contenus dans les Dépôts locaux
-
Toutes les persistances des Entités Métier et des Datablocks
-
Les classements créés dans le Projet à supprimer
-
Ajout d’un Connecteur Neo4j : Un nouveau Connecteur Neo4J a été ajouté (base de données de type graphe).
Ajout d’un Dépôt de type Neo4j : Un nouveau Dépôt permettant la saisie d’une requête Cypher basée sur un Connecteur Neo4J a été ajouté.
Dépôts / Téléchargement : Il est désormais possible de télécharger les fichiers contenus dans les Dépôts locaux.
Explorateur de fichiers : Un explorateur de fichier a été ajouté permettant d’explorer le contenu distant. Cet explorateur est disponible pour les Connecteurs HDFS, MinIO, S3 et SFTP.
La fonction "explorer" est disponible au niveau des fonctions Connecteurs, Dépôts et lors du paramétrage des Exports. Cette fonction permet de visualiser les fichiers distants. Pour les fonctions Dépôts et Export, l’explorateur permet de choisir le chemin cible. Seuls les répertoires peuvent être choisis.
Suppression des Publications de Tableaux de bords : Il est désormais possible de supprimer une ou plusieurs Publications d’un Tableau de bord.
| Un Tableau de bord ne peut pas être supprimé tant qu’il contient des Publications actives et/ou archivées. Pour réaliser la suppression d’un Tableau de bord, il est nécessaire de supprimer l’ensemble des Publications liées. |
Pour supprimer les Publications, accéder en édition au Tableau de bord puis utiliser l’onglet Publications.
Plusieurs cas sont traités lors de la suppression d’une Publication, à savoir :
-
La Publication est active mais n’a jamais été consultée : dans ce cas, suite à sa confirmation, la suppression est définitive et immédiate.
-
La Publication est active et a déjà été consultée : Dans ce cas, suite à la confirmation, la Publication change de statut et devient une Publication archivée.
Ajout d’un parser URI pour les Dépôts sur Connecteur HTTP/HTTPS : Ajout d’un parser de l’URI, permettant une saisie plus structurée des paramètres de l’URI. Cette fonction n’est disponible que pour les Dépôts sur Connecteur de type Http/Https.
Mise à jour version AngularJs et intégration de la stack Angular : Depuis la version 7.6 et en vue des migrations futures de certains écrans ou nouvelles évolutions, la stack Angular a été intégrée.
Version 7.5.4
Correctifs
-
Amélioration de la prise en charge des fichiers accentués sur le Connecteur SFTP
-
Corrections de la gestion de l’encodage sur les flux du Connecteur HTTP (détection et prise en charge)
-
Autorisation d’utiliser les mêmes endpoints pour les Expositions lors de l’import d’un Projet
-
Utilisation de la langue du navigateur dans les Publications
-
Amélioration de la prise en charge des fichiers excel
Version 7.5.0
Evolutions
Duplication de Projet : Un Projet peut désormais être dupliqué au sein de la même instance de DataChain.
Export/Import de Projet : Un Projet peut être exporté d’une instance DataChain, pour ensuite être importé dans une autre instance. Cet import/export peut porter sur tout ou partie des éléments du Projet. Traçabilité des exports de Projet : Un nouvel écran permet de visualiser les traces des exports de Projet de l’instance. Cet écran est accessible depuis GenericsData.
À partir du menu gauche, cliquer sur “Traçabilité Exports”.
Depuis l’écran, deux onglets sont disponibles
* Éléments : Suivi des exports DataBlocks
* Projets : Suivi des exports de Projet
** Depuis chaque ligne de trace, il est possible de télécharger à nouveau le fichier généré à la date de l’action d’export.
Correctifs
-
Gestion des droits par lot pour les membres d’un Projet de type Groupe depuis l’écran d’administration
-
Correction d’un problème d’affichage des critères cibles de jointure à l’édition d’une jointure depuis les étapes d’un DataBlock
-
Divers correctifs mineurs ou améliorations concernant les nouvelles fonctions Duplication de Projet et Export/Import de Projet
Version 7.4.1
Evolutions
Datablock : Amélioration de la fonction Export CSV : De nouveaux paramètres sont disponibles pour la réalisation des exports de type CSV.
Correctifs et améliorations
-
Au niveau de la sortie d’étape des Datablocks, amélioration de la fonction remplacement des nulls par une valeur pour les colonnes de type décimal. La prise en charge des valeurs NaN est désormais traitée comme les valeurs null
-
Statistiques sur colonnes de type Date. Suite à la migration Spark 3, une erreur lors de la réalisation des statistiques des colonnes de type Date a été prise en charge
-
Amélioration de la page Accueil d’un Projet. Ajout d’un filtre sur la colonne type d’action
-
Correction d’un problème bloquant empêchant de modifier un mot de passe de Dépôt, suite à la mise en place de la clé de chiffrement complémentaire
Version 7.4.0
Evolutions
- Migration Spark 2.4. vers Spark 3.03
-
-
Intégration Spark 3 : DataChain intègre désormais le moteur Spark 3 (version 3.0.3) en lieu et place de Spark 2.4.
Pour plus d’informations sur les évolutions et modifications liées à la version de Spark 3, voir ici : https://Spark.apache.org/docs/3.0.3/sql-migration-guide.html
-
Des gains de performances ont été observés sur notre plateforme en mode mono-nœud ou en mode cluster. Toutes les images utilisent désormais la version 11 de Java.
-
Cluster Spark 3 : Nous mettons à disposition un cluster Spark 3 et un cluster hadoop, basés sur le même modèle que les images qui ont été précédemment proposées (images “bde2020” hadoop et Spark).
Un nouveau repository est disponible sur notre registry harbor (avec une clé dédiée, afin de mettre ces images à disposition).
Le repository est “ado-spark-hadoop” et les images sont en version 1.0.0
b9kd47jn.gra7.container-registry.ovh.net/ado-spark-hadoop/master-spark-3.0.3-hadoop-3.2:1.0.0 b9kd47jn.gra7.container-registry.ovh.net/ado-spark-hadoop/worker-spark-3.0.3-hadoop-3.2:1.0.0 b9kd47jn.gra7.container-registry.ovh.net/ado-spark-hadoop/namenode-hadoop-3.3.2:1.0.0 b9kd47jn.gra7.container-registry.ovh.net/ado-spark-hadoop/datanode-hadoop-3.3.2:1.0.0
Ces images remplacent les images utilisées précédemment
bde2020/spark-master:2.4.5-hadoop2.7 bde2020/spark-worker:2.4.5-hadoop2.7 bde2020/hadoop-namenode:2.0.0-hadoop2.7.4-java8 bde2020/hadoop-datanode:2.0.0-hadoop2.7.4-java8
Gestion des Valeurs NaN (Not a Number) : la gestion des valeurs NaN est désormais prise en charge pour les colonnes de type décimal
-
QueryBuilder (Gestionnaire de règles et de filtres) : Au niveau du QueryBuilder, un nouvel opérateur permet de filtrer (ou de conserver) les valeurs NaN.
-
Gestionnaire de formules : Une nouvelle formule est disponible pour transformer les valeurs NaN en valeurs "Null".
Nom de la formule : dec.nan_to_null(Argument 1) Description : Transforme les valeurs NaN en null Argument 1 : Colonne de type Décimale
-
DataBlock : Sortie d’étape : La fonction de remplacement des valeurs Null a été étendue.
Cette fonction prend désormais en compte les valeurs de type NaN au même titre que les valeurs Null.
Les statistiques de colonnes prennent en charge les valeurs de type NaN
Version 7.3.2
Evolutions
Correction de sécurité suite à un audit
-
Gestion des cookies : L’application DataChain ne génère désormais plus de cookie. Seuls les cookies KeyCloak perdurent, car ils sont inhérents au produit lui-même.
Afin de positionner ces cookies à Secure, il faut que la configuration du royaume soit positionnée à Require SSL : all request (modification à effectuer dans le royaume dc-realm, onglet login).
Les cookies de session ne peuvent être marqués comme http_only, pour des raisons de fonctionnalité du produit Keycloak (voir ici https://lists.jboss.org/pipermail/keycloak-user/2017-September/011882.html et https://issues.redhat.com/browse/KEYCLOAK-12880) -
Externalisation du mot de passe de base de données : Le mot de passe des bases de données peut être surchargé via des variables d’environnement du Docker compose de DataChain.
Pour toutes les images postgresql, la clé est POSTGRES_PASSWORD.
L’image PG_MIGRATION devra avoir les variables d’environnement qui conviennent pour fonctionner lors des dumps
PG_PASSWORD, PG_KC_PASSWORD et PG_EXPOSE_PASSWORD
-
Renforcement du chiffrement des mots de passe dans la base de données :
Les mots de passe sont, jusqu’à ce jour, chiffrés en base de données. La clé de chiffrement est cependant unique pour tous les environnements. Il est désormais possible de surcharger la clé de chiffrement existante (nouveau paramètre applicatif (16 caractères obligatoirement) à déclarer pour l’image backend et l’image Spark de l’application : dc.app.backend.cipher.key). Ce paramètre est concaténé avec la clé de chiffrement interne de l’application.
Attention, en cas de mise en œuvre de ce paramètre, les mots de passe précédemment configurés devront être modifiés via l’interface de l’application, afin de pouvoir être utilisables par l’application. Ce paramètre devrait donc être mis en œuvre lors de la première installation, puis non modifié par la suite.
Script de détection de non-concordance de type des Datablocks en anomalie suite au passage 7.3.0
Ce script analyse l’ensemble des unions et jointures présentes dans les étapes des DataBlocks d’une instance DataChain. L’analyse met en évidence les incohérences de type entre les colonnes sources et cibles des critères de jointure et/ou d’union. Un rapport indique les DataBlocks dont au moins un couple de colonne est en incohérence. Les DataBlocks concernés devront faire l’objet d’un re-mapping pour les colonnes concernées.
L’exécution du script se fait via la commande suivante sur le serveur ou se trouve l’instance DataChain
Docker run -v /tmp:/scripts_outputs -it --network nom_du_reseau_DataChain -e PG_HOST=dc-pg --entrypoint bash dc/pg_migration:7.3.2 utils.sh detectUnionsJoinsImpact.groovy
Les éléments en gras sont à adapter à l’InstanceDataChain nom_du_reseau_DataChain : se trouve dans le fichier Docker compose de DataChain (ex : dc_network) dc/pg_migration:7.3.2 : nom de l’image Docker à utiliser, à préfixer par le repository Docker utilisé /tmp : nom du répertoire dans lequel sera déposé le fichier rapport, après exécution du script.
Il est possible que le réseau actuel de Docker ne supporte pas l’exécution d’un conteneur externe (l’exécution génère une erreur indiquant l’impossibilité de se connecter au réseau). Dans ce cas, éditer le fichier Docker-compose.yml et trouver la description des réseaux en fin de fichier et le réseau de DataChain