Créer une nouvelle connexion - détails de la configuration

Importation à partir du catalogue - détails de la configuration

Importation à partir d'un projet - détails de la configuration

Processus BYOJ (Bring Your Own JAR)

Voici la procédure à suivre pour ajouter votre propre JAR à la source de données MySQL:

1. Connectez-vous à l'instance IBM® watsonx.data.
2. Dans le menu de navigation, allez à la page Configurations et cliquez sur la tuile Gestionnaire de pilotes.
3. Cliquez sur Ajouter un pilote.
4. Téléchargez le JAR MySQL et indiquez la version du pilote. Actuellement, un seul JAR mysql-connector-j-8.2.0.jar ) est pris en charge pour la source MySQL dadata.
5. Cliquez sur Ajouter. Une fois le conducteur ajouté avec succès, il est soumis à une série de validations. Si la validation est réussie, elle passe à l'état "inactif", sinon elle passe à l'état "échec".
6. Cliquez sur l'icône de l'ellipse verticale pour attribuer ou supprimer le pilote.
7. Pour affecter le conducteur à un moteur :
   • Cliquez sur Affecter.
   • Sélectionnez un ou plusieurs moteurs pour affecter le conducteur. Une fois attribué, le conducteur est mis en statut "actif".
8. Pour désaffecter un conducteur d'un moteur, les utilisateurs doivent d'abord introduire un autre conducteur.
9. Cliquez sur Enregistrer et redémarrez le moteur.
10. Dans le gestionnaire d'infrastructure, survolez la source de données MySQL et cliquez sur l'icône Gérer les associations.
11. Sélectionnez le moteur pour modifier l'association du catalogue avec celui-ci. Toutes les requêtes en vol sur les moteurs modifiés sont arrêtées.
12. Cliquez sur Enregistrer et redémarrez le moteur.

Vous ne pouvez lier la source de données MySQL au moteur que si un pilote est associé à ce moteur. Un seul pilote MySQL peut être associé à un moteur à la fois.

Vulnérabilités dans les JAR

Dans le cadre du processus BYOJ, les utilisateurs peuvent télécharger les fichiers JAR requis. Si une vulnérabilité est identifiée dans un JAR, un délai de grâce est fixé pour les activités de retrait et de nettoyage en fonction de la gravité de la vulnérabilité de sécurité, comme indiqué dans le tableau suivant :

Le délai de grâce est calculé à partir de la date à laquelle la vulnérabilité est signalée, plus le délai de grâce spécifié. Plusieurs avertissements sont affichés à l'intention des utilisateurs concernant le délai de grâce dans la page Gestionnaire de pilotes (pour l'administrateur) ainsi qu'à d'autres endroits tels que la section "Catalogues" dans la page "Gestionnaire d'infrastructure" et la section "Catalogues associés" dans la page "Gestionnaire de données". Par exemple, si un client utilise le site mysql-connector-j-8.2.0.jar et qu'une vulnérabilité critique est identifiée le 1er octobre, un processus de nettoyage commence immédiatement après le 31 octobre. Ce processus supprime le pilote du seau et des pods Presto, dissocie le catalogue du moteur, dissocie le pilote dans la page Driver Manager et supprime l'entrée.

Impact de la mise à jour sur les catalogues MySQL (version 2.1.0

A quoi s'attendre après la mise à jour vers la version 2.1.0: de watsonx.data

Lorsque vous passez à la version 2.1.0 de watsonx.data, les catalogues MySQL existants sont dissociés du moteur. Cela signifie que vous devez réassocier le catalogue MySQL au moteur.

Etapes pour réassocier le catalogue MySQL:

Pour réassocier le catalogue MySQL au moteur, téléchargez le fichier JAR mysql-connector-j:8.2.0 dans le gestionnaire de pilotes en suivant la procédure BYOJ.

Limitations des instructions SQL

• Seulement CREATE TABLE AS est pris en charge pour CREATE TABLE déclaration.
• DROP TABLE L'instruction est prise en charge uniquement lorsqu'elle est activée dans le catalogue.
• Pour les catalogues basés sur des sources de données, les déclarations CREATE SCHEMA, CREATE TABLE, DROP SCHEMA, DROP TABLE, DELETE, DROP VIEW, ALTER TABLE et ALTER SCHEMA ne sont pas disponibles dans l'interface utilisateur du Gestionnaire de données.

Limitations des types de données

• BLOB et CLOB prise en charge des types de données SELECT déclaration mais ne prend pas en charge les opérations telles que equal,like, et in.
• BINARY le type de données prend en charge uniquement SELECT déclaration.
• Les données affichées à partir de l'interface utilisateur pour BLOB le type de données est dansBase64 format, tandis que le résultat de presto-cli est au format hexadécimal.
• Les données affichées à partir de l'interface utilisateur pour BINARY le type de données est dansBase64 format, tandis que le résultat de presto-cli est au format hexadécimal.
• Vous pouvez utiliser CLOB type de données comme alternative équivalente à LONGTEXT.
• Lorsque les champs de type de données REAL avoir 6 chiffres ou plus dans la partie décimale, les chiffres étant principalement zéro, les valeurs interrogées sont arrondies. On constate que les arrondis s'effectuent différemment selon la précision des valeurs. Par exemple, un nombre décimal de 1.654, arrondi à 3 chiffres après la virgule, est identique. Un autre exemple est 10.890009 et 10.89000. On remarque que10.89000 est arrondi à10.89, alors que10.89009 n’est pas arrondi. Il s'agit d'un problème inhérent en raison des limitations de représentation des formats binaires à virgule flottante. Cela peut avoir un impact significatif lorsque l’interrogation implique un tri.