Creare una nuova connessione - dettagli di configurazione

Importazione da catalogo - dettagli di configurazione

Importazione dal progetto - dettagli di configurazione

Processo BYOJ (Bring Your Own JAR)

Di seguito viene descritta la procedura per aggiungere il proprio JAR all'origine dati MySQL:

1. Accedere all'istanza IBM® watsonx.data.
2. Dal menu di navigazione, andare alla pagina Configurazioni e fare clic sul riquadro Gestione driver.
3. Fare clic su Aggiungi driver.
4. Caricare il JAR di MySQL e specificare la versione del driver. Attualmente, solo un JAR mysql-connector-j-8.2.0.jar ) è supportato per la sorgente MySQL dadata.
5. Fai clic su Add. Una volta aggiunto con successo, il driver viene sottoposto a una serie di convalide. Se la convalida ha successo, viene impostata sullo stato "inattivo", altrimenti sullo stato "fallito".
6. Fare clic sull'icona a forma di ellisse verticale per assegnare o eliminare il driver.
7. Per assegnare il conducente a un motore:
   • Fai clic su Assegna.
   • Selezionare uno o più motori da assegnare al conducente. Una volta assegnato, il conducente è impostato sullo stato "attivo".
8. Per disassegnare un driver da un motore, l'utente deve prima introdurre un altro driver.
9. Fare clic su Salva e riavviare il motore.
10. Nel Gestore dell'infrastruttura, passare il mouse sull'origine dati MySQL e fare clic sull'icona Gestisci associazioni.
11. Selezionare il motore per modificare l'associazione del catalogo con esso. Tutte le interrogazioni in volo sui motori modificati vengono interrotte.
12. Fare clic su Salva e riavviare il motore.

È possibile collegare l'origine dati MySQL al motore solo quando un driver è associato a tale motore. A un motore può essere associato un solo driver MySQL alla volta.

Vulnerabilità in JAR

Come parte del processo BYOJ, gli utenti possono caricare i file JAR richiesti. Se viene identificata una vulnerabilità in un JAR, viene stabilito un periodo di tolleranza per le attività di rimozione e pulizia in base alla gravità della vulnerabilità di sicurezza, come mostrato nella tabella seguente:

Il periodo di grazia viene calcolato a partire dalla data di segnalazione della vulnerabilità, più il periodo di grazia specificato. Nella pagina Driver manager (per l'amministratore) e in altri punti, come la sezione "Cataloghi" nella pagina "Infrastructure manager" e la sezione "Cataloghi associati" nella pagina "Data manager", vengono visualizzati diversi avvisi agli utenti sul periodo di tolleranza. Ad esempio, se un cliente utilizza il sito mysql-connector-j-8.2.0.jar e il 1° ottobre viene identificata una vulnerabilità critica, il processo di pulizia inizia immediatamente dopo il 31 ottobre. Questo processo elimina il driver dal bucket e dai pod Presto, dissocia il catalogo dal motore, dissocia il driver nella pagina Driver Manager ed elimina la voce.

Impatto dell'aggiornamento sui cataloghi MySQL (versione 2.1.0 )

Cosa aspettarsi dopo l'aggiornamento alla versione watsonx.data 2.1.0:

Quando si esegue l'aggiornamento a watsonx.data versione 2.1.0, i cataloghi MySQL esistenti vengono dissociati dal motore. Ciò significa che è necessario riassociare il catalogo MySQL con il motore.

Passi per riassociare il catalogo MySQL:

Per riassociare il catalogo MySQL al motore, caricare il file JAR mysql-connector-j:8.2.0 nel gestore dei driver seguendo la procedura BYOJ.

Limitazioni per le istruzioni SQL

• Soltanto CREATE TABLE AS è supportato per CREATE TABLE dichiarazione.
• DROP TABLE l'istruzione è supportata solo se abilitata nel catalogo.
• Per i cataloghi basati sulle fonti di dati, le dichiarazioni CREATE SCHEMA, CREATE TABLE, DROP SCHEMA, DROP TABLE, DELETE, DROP VIEW, ALTER TABLE e ALTER SCHEMA non sono disponibili nell'interfaccia utente Data Manager.

Limitazioni per i tipi di dati

• BLOB E CLOB supporto dei tipi di dati SELECT istruzione ma non supportano operazioni come equal,like, E in.
• BINARY il tipo di dati supporta solo SELECT dichiarazione.
• I dati mostrati dall'interfaccia utente di BLOB è presente il tipo di datiBase64 formato, mentre il risultato di presto-cli è in formato esadecimale.
• I dati mostrati dall'interfaccia utente di BINARY è presente il tipo di datiBase64 formato, mentre il risultato di presto-cli è in formato esadecimale.
• Puoi usare CLOB tipo di dati come alternativa equivalente a LONGTEXT.
• Quando i campi di tipo dati REAL hanno 6 o più cifre nella parte decimale con predominanza di zero, i valori quando interrogati vengono arrotondati. Si osserva che l'arrotondamento avviene diversamente a seconda della precisione dei valori. Ad esempio, un numero decimale 1.654 se arrotondato a 3 cifre dopo la virgola è lo stesso. Un altro esempio è rappresentato da 10.890009 e 10.89000. Lo si nota10.89000 è arrotondato a10.89, mentre10.89009 non è arrotondato. Questo è un problema intrinseco a causa delle limitazioni rappresentative dei formati binari in virgola mobile. Ciò potrebbe avere un impatto significativo quando l'esecuzione di query implica l'ordinamento.