In questo esempio, useremo una funzione.

Creiamo un file che contenga i test, chiamamolo risultati_test.sql.

Scriviamo la funzione che lancia i test direttamente nel file, con il nostro editr preferito.

CREATE OR REPLACE FUNCTION risultati_test()
    RETURNS SETOF TEXT
AS $$
BEGIN

    -- Controlliamo la presenza degli oggetti:
    -- Tabella foo
    RETURN NEXT tables_are(
        'public',
        ARRAY[ 'foo' ]
    );

    -- Schema nuovo_schema
    RETURN NEXT schemas_are(
        ARRAY['public','nuovo_schema']
    );

    -- Controlla che sia presente la funzione say_hello
    RETURN NEXT can(
        ARRAY['say_hello']
    );

    -- Controlla che la funzione say_hello sia scritta in SQL
    RETURN NEXT function_lang_is(
        'say_hello',
        'sql'
    );

    -- Controlla che la funzione say_hello non generi errori
    RETURN NEXT lives_ok(
        'SELECT say_hello()'
    );

    -- Controlla che la tabella foo contenga esattamente certi valori
    -- provate a cambiare uno dei valori ed osservare come si comporta il test
    RETURN NEXT results_eq(
        'SELECT * FROM foo',
        'VALUES (1),(2),(3),(4),(5)'
    );

END;
$$ LANGUAGE plpgsql;

Adesso creiamo il file che esegue questa funzione, chiamiamolo test.sql

BEGIN;
\i risultati_test.sql
SELECT PLAN(6); -- Necessario!
SELECT risultati_test();
ROLLBACK;

• La prima riga dà inizio ad una transazione. È consigliato inserire i test in una transazione che esegua un rollback prima di terminare, così da essere sicuri che lo stato del databse venga mantenuto intatto.

• Successivamente, tramite il comando di psql \i, importiamo il file risultati_test.sql, che crea la funzione che lancia i test.

• La riga successiva, SELECT PLAN(6);, serve a specificare il numero di test che intendiamo eseguire (6 in questo caso). È necessaria e controlla che l'esecuzione di un numero di test diverso rispetto a quello specificato, restituisca un fallimento.

• La riga SELECT risultati_test(); lancia la funzione che esegue i test.

Abbiamo finito di scrivere i nostri test, possiamo eseguirli con:

psql -f test.sql pgtap_db

Il risultato dovrebbe essere:

BEGIN
CREATE FUNCTION
 plan
------
 1..6
(1 row)

                     testfunction
------------------------------------------------------
 ok 1 - Schema public should have the correct tables
 ok 2 - There should be the correct schemas
 ok 3 - Schema pg_temp_2 or pg_catalog or public can
 ok 4 - Function say_hello() should be written in sql
 ok 5
 ok 6
(6 rows)

ROLLBACK

Si spiega da solo, no? :)

In effetti, lo scopo del protocollo TAP è di essere il più comprensibile possibile. Una serie di ok (in caso di successo) e di not ok (in caso di fallimento) rendono estremamente facile l'interpretazione dei test.

2ndQuadrant Italia utilizza estensivamente PgTAP, il tempo speso a scrivere i test risulta di vitale importanza per la manutenzione dei nostri progetti.

PgTAP, sfruttando una sintassi estremamente semplice, permette di testare a fondo il proprio database.

Presupponendo che PgTAP sia stato installato correttamente in un database chiamato pgtap_db, procediamo con la creazione di alcuni oggetti sui quali eseguiremo dei test.

Per informazioni circa l'installazione di PgTAP in un determinato database, rimando alla documentazione ufficiale.

$ psql -c "CREATE TABLE foo AS SELECT generate_series(1,5) AS x" pgtap_db
SELECT 1
$ psql -c "CREATE SCHEMA nuovo_schema" pgtap_db
CREATE SCHEMA
$ psql -c "CREATE FUNCTION say_hello() RETURNS TEXT LANGUAGE SQL AS $$SELECT 'Hello World'::TEXT$$;" pgtap_db
CREATE FUNCTION

Tipi di utilizzo

PgTAP può essere utilizzato per testare qualsiasi aspetto del database. In particolare:

• Presenza di oggetti nel database
• Controllo dell'esecuzione di query
• Controllo dei risultati di una query
• Altro

Descriverò in ordine questi aspetti e poi vedremo un esempio pratico.

Presenza di oggetti nel database

Si può controllare l'esistenza di qualsiasi tipo di oggetto nel database. Questo tipo di funzioni ha più o meno la stessa firma, in particolare:

*tipo_di_oggetto*_are( [schema,]  [,description] )

Dove:

• tipo_di_oggetto è la categoria di oggetti di cui vogliamo testare la presenza, ad esempio tabelle (tables), funzioni (functions), schemi (schemas) ecc.

• schema definisce lo schema in cui gli oggetti devono trovarsi, questo parametro ha senso solo se non si sta testando la presenza dello schema stesso.

• array_di_nomi è un array contenente i nomi degli oggetti che devono essere presenti perchè il test abbia successo

Importante: Per avere successo, tutti gli elementi specificati nell'array devono essere presenti. In caso di assenza di almeno uno degli elementi, il test fallirà.

• description è una descrizione del test

Nota: Ovviamente, nel caso di schemas_are, il primo parametro, schema, viene omesso.

Controllo dell'esecuzione di query

È possibile testare in modo semplice che una query venga eseguita senza o con errori. Per farlo sono disponibili le funzioni:

throws_ok( query [, errcode] [, errmsg] [, description] )
lives_ok( query [, description] )
performs_ok( query, milliseconds [, description])

Queste tre funzioni controllano rispettivamente:

• Che la query generi un'eccezione. È possibile specificare l'errore voluto tramite il parametro errcode

• Che la query non generi un'eccezione

• Che la query termini entro milliseconds millisecondi

Controllo dei risultati di una query

Spesso si ha bisgno di controllare che una query restituisca esattamente un certo insieme di risultati. PgTAP ha diverse funzioni per questo scopo, la principale è:

results_eq( sql, array [, description] )

Molto intuitivamente, questo test passerà se l'insieme di risultati della query sarà esattamente uguale ai valori presenti in array. Nell'esempio completo presente più in basso, vedremo come sfruttare questa funzione.

Altro

Vi sono poi altri tipi di test, ma citiamo qui solo i più importanti. Per una lista completa invitiamo a consultare la documentazione ufficiale.

• Per controllare qualsiasi elemento usando un'espressione regolare:

matches( anyelement, regex [, description] )

• Per controllare che un utente sia un superutente:

is_superuser( user [, description] )

• Per controllare che una funzione sia scritta in un determinato linguaggio:

function_lang_is( [schema,] function [, args[]] , language [, description])

• Per stampare messaggi di diagnostica che non interferiscano con i test:

diag( text )

Nel prossimo articolo vedremo un esempio pratico, dove eseguiremo dei test su un set di oggetti creati per l'occasione.

A presto!

Creiamo quindi le connessioni alle risorse che ci serviranno durante l'importazione, ovvero la connessione al database remoto e i due file csv.

Nella sezione Metadata dell'interfaccia di Talend, aggiungiamo la connessione a Greenplum, dopo aver inserito il nome e i parametri di connessione, il programma creerà un nuovo oggetto di tipo DbConnection.

Cliccando su questo con il tasto destro e selezionando l'opzione "recupera schema", sarà possibile selezionare le tabelle su cui vogliamo lavorare, nel nostro caso la tabella states e la tabella users.

Aggiungiamo ora i file contenenti i dati. Subito sotto l'icona delle connessioni ai database (DB connections), troviamo il gruppo dei file CSV, come precedentemente fatto per i database, clicchiamo con il tasto destro sul gruppo e poi su "crea file delimitato".

Nella prima schermata del wizard che si aprirà, ci verrà richiesto di inserire un nome e una descrizione per la risorsa che stiamo creando. Si passa quindi allo step due, nel quale dobbiamo identificare il file di testo a cui vogliamo riferirci, e la sua codifica. Una volta fatto sarà possibile possibile passare al terzo step, nel quale dobbiamo istruire Talend su come gestire le colonne del CSV. In questa schermata è possibile : selezionare l'encoding del file (1), i separatori di campo e i caratteri di fine linea (2), e qualora fosse necessario, segnalare quante e quali linee devono essere ignorate sia all'inizio che alla fine del file (3). È inoltre possibile segnalare a Talend di utilizzare la prima riga come "schema" del CSV, in maniera che possa prendere i nomi delle colonne direttamente dal file, risparmiando all'utilizzatore l'inserimento manuale del nome delle colonne ( 4 ).

Nel quarto step resta solo da: modificare lo schema del file che stiamo associando, controllare e modificare i tipi di dato riconosciuti in automatico per ogni colonna e, qualora non fossero stati riconosciuti in automatico dalla testata del CSV, modificare i nomi delle colonne e la lunghezza dei campi.

Completato il 4° passo del wizard, il file è correttamente associato all'applicazione e pronto per essere usato.

Una volta aggiunte tutte le risorse che intendiamo utilizzare, è possibile procedere con la creazione del job. Trasciniamo quindi i due file sull'editor visuale del job, e selezioniamo tFileInputDelimited come tipo di file.

Dalla connessione a Greenplum precedentemente creata invece, trasciniamo sull'editor le due tabelle di destinazione (nel nostro caso states e users), e selezioniamo come tipo tGreenplumOutput.

Inseriamo ora un oggetto di tipo tMap - che si trova nella palette degli strumenti alla destra dell'editor visuale - nella cartella "elaborazione" e posizioniamolo fra il file CSV contenente gli stati da importare e la tabella di Greenplum di destinazione. Colleghiamo il file al componente tMap (clic con il destro sul file -> riga -> main) e il componente tMap alla tabella di destinazione (clic destro sulla tabella -> riga -> nuovo output). Una volta collegati fra di loro i componenti possiamo fare doppio click sull'oggetto tMap che permette di associare le righe del file da importare a quelle della tabella di destinazione.

Trascinando i vari campi dalla tabella di sinistra a quella di destra , è possibile associare ogni colonna del file alla colonna relativa sulla tabella di destinazione. Cliccando su ok salveremo l'associazione appena effetuata e i dati sono pronti per essere importati dal file di origine alla tabella di destinazione.

Aggiungiamo ora l'importazione di una lista di utenti dal secondo csv, durante l'importazione è necessario fare lookup sulla tabella degli stati appena riempita, in maniera da verificare l'associazione "utente -> stato", riga per riga. Con il gergo lookup si intende la ricerca di un valore all'interno di un dizionario, utilizzando una chiave al fine di recuperare un ID (solitamente la chiave primaria di quell'oggetto nel database, per garantire integrità referenziale).

Aggiungiamo quindi un oggetto tMap fra il file CSV con gli utenti e la tabella di destinazione, inoltre dalla lista delle tabelle di Greenplum trasciniamo nuovamente la tabella contenente gli stati sulla finestra dell'editor visuale, selezionando come tipo tGreenplumInput.

Colleghiamo quindi i tre elementi al componente tMap, come e' stato fatto precedentemente.

Adesso eseguiamo il mapping fra i tre elementi: questa volta il campo idState del CSV deve essere mappato sul campo idState della tabella states (row3) e quest'ultimo deve essere collegato alla tabella utenti di destinazione. In questa maniera per ogni linea del CSV viene eseguito il lookup sulla tabella stati, assicurando così l'integrità della relazione "Utente - Stato".

Per concludere, facciamo in modo che prima venga eseguita l'importazione dei dati relativi agli stati. Successivamente, quelli degli utenti, in modo da poter eseguire correttamente il lookup. Tracciamo quindi una riga di tipo OnComponentOK (click destro -> attivare -> onComponentOk) dal componente di output della tabella stati a quello di input degli utenti (il file CSV).

In questo modo prima verrano importati gli stati e solo in caso di successo verranno impotati gli utenti.

Adesso basterà cercare il tab di esecuzione nella parte bassa dell'area di lavoro e premere il tasto run per fare in modo che il nostro job venga eseguito.