Rilasciato STK/Unit 1.0 Release Candidate 1

English announcement

E’ uscito STK/Unit 1.0 Release Candidate 1!

STK sta per SQL ToolKit. Si tratta di una famiglia di progetti per MariaDB, MySQL e Percona Server. STK/Unit è il primo progetto STK a essere rilasciato pubblicamente; altri arriveranno nel prossimo futuro. L’obiettivo di STK nel lungo termine è rendere la programmazione SQL molto più semplice ed affidabile su MariaDB e le sue sorelle.

STK/Unit è una piattaforma di Unit Test per MariaDB, interamente scritta in SQL e ispirata da SimpleTest e JUnit. I Test Case e le Test Suite scritti dall’utente possono creare un ambiente di test e verificare che tutte le operazioni producano i risultati previsti. I risultati possono essere estratti come stringa leggibile, in formato HTML, o esaminati nelle tabelle nelle quali vengono scritti. Tanto gli sviluppatori quanto gli amministratori di database possono trarre beneficio da STK/Unit.

Gli errori che si verificano nelle applicazioni possono avere origine nei database. STK/Unit è progettato principalmente per testare le strutture SQL attive: Stored Routine, Trigger, vincoli di integrità e Viste. Ma anche le tabelle devono servirsi dei tipi di dati, dimensioni delle colonne e set di caratteri adatti a contenere i dati che arrivano dal Mondo Reale. Inoltre gli aggiornamenti del DBMS, i nuovi plugin e perfino i cambiamenti nella configurazione possono portare anomalie nelle complesse e delicate logiche dei database relazionali. Ma un buon set di test può far emergere i problemi appena questi si verificano!

STK/Unit è ancora in sviluppo e sta espandendo il parco di piattaforme supportate; attualmente, funziona sulle seguenti:
* MariaDB 5.5 e 10.0 – funziona bene
* MariaDB 5.3, 5.2, 5.1 – con problemi minori, documentati
* MySQL 5.1 – utilizzando MyISAM invece di Aria, con problemi minori (non documentati al momento)

La Documentazione e i Download di STK/Unit e degli altri strumenti STK che verranno sono reperibili qui:
http://stk.wikidot.com/

La Mailing List pubblica si trova qui:
https://launchpad.net/~stk-discuss

Il team di STK incoraggia tutti a provare STK/Unit nei propri database, segnalare qualsiasi bug venga riscontrato, chiedere aiuto in lista se necessario, e farci avere i vostri commenti. I vostri feedback hanno un grande valore per noi!

Il team di STK

Annunci

Impostare un SQL_MODE restrittivo

English version

Sviluppare Stored Routine, Trigger o Evente per MariaDB e MySQL non è facile, perché il linguaggio manca di flessibilità e ha molte limitazioni. In più, il server tenta di facilitarci la vita nascondendoci gli errori e permettendo cattive pratiche. Secondo la mia modesta opinione, se si devono scrivere più di 3 righe, le cattive pratiche rendono le cose esponenzialmente più ardue. Quando il server si lamenta perché hai fatto qualcosa di sbagliato, il problema non è nel server stesso: è nel tuo codice! E rimane lì anche se dici al server di tacere. L’unica soluzione ragionevole è trovare il problema e modificare il codice. Perciò suggerisco di far sì che il server sia petulante. Per fare questo, occorre modificare il valore della variabile SQL_MODE.

L’SQL_MODE può modificare SQL syntax, rendendola più compatibile con altri DBMS. Personalmente non amo usare sintassi che non siano standard de facto, ma credo sia una pratica innocua.

Alcuni flag però dovrebbero sempre essere impostati, perché fanno sì che il server non sia eccessivamente flessibile.

ERROR_FOR_DIVISION_BY_ZERO
I numeri non possono essere divisi per zero, perché il risultato non è definito. Se si tenta di eseguire tale operazione, la maggioranza dei linguaggi risponde con un errore. Lo fa anche MariaDB, se questo flag è impostato. Altrimenti, restituisce NULL. Siccome il valore NULL corretto, da un punto di vista logico, per rappresentare un valore non definito, questo comportamento potrebbe andare bene. Ma di solito non è una cosa desiderata – se si divide per zero per errore, è bene esserne informati e correggere il bug!

NO_AUTO_CREATE_USER
Quando si utilizza GRANT per assegnare dei permessi a un utente che non esiste, esso viene creato automaticamente, a meno che questo flag sia impostato. Dal punto di vista della sicurezza, non è una buona cosa che si possa creare un utente per errore.

NO_AUTO_VALUE_ON_ZERO
Questo flag permette di inserire il valore 0 in un campo AUTO_INCREMENT. Poiché 0 è un valore lecito, in genere questo flag dovrebbe essere impostato. Ma non me ne curo molto, perché modificare una colonna AUTO_INCREMENT è secondo me una cattiva pratica.

NO_ENGINE_SUBSTITUTION
Quando si crea una tabella, è importante scegliere lo Storage Engine più appropriato. Se questo flag non è impostato, e si specifica uno Storage Engine che non esiste, il server utilizzerà quello di default.

NO_ZERO_DATE
Se questo flag non è impostato, MariaDB accetta un valore data speciale: ‘0000-00-00’. Se si desidera utilizzarlo, non occorre impostare questo flag; ma non è una situazione comune. In caso contrario è soltanto una fonte di problemi, perché le date non valide verranno convertite in date-zero senza avviso. E questo non è quasi mai ciò che si vuole che accada.

NO_ZERO_IN_DATE
Questo flag impedisce che le date non-zero possano contenere delle parti-zero, come ‘0000-05-20’ o ‘1994-00-01′. E’ un po’ meno usuale creare una data di questo genere per errore, ma può accadere se si compone dinamicamente una data come stringa.

ONLY_FULL_GROUP_BY
Quando si specifica una colonna non aggregata e non raggruppata in una clausola SELECT, il risultato non è definito. Per questo motivo dovrebbe essere generato un errore, ma ciò accade solo se questo flag è impostato.

STRICT_ALL_TABLES
Questo flag è molto importante perché, se non è impostato, non viene generato alcun errore quando si tenta di inserire un valore fuori dall’intervallo consentivo (o una stringa troppo lunga). Funziona non soltanto per le tabelle, ma anche per le variabili e le funzioni. Per esempio, se una funzione dichiarata come TINYINT SIGNED tenta di restituire 200, non viene generato alcun errore (solo un warning), e il valore restituito è 127. Un problema di questo genere può essere difficile da debuggare.

STRICT_TRANS_TABLES
Vedi STRICT_ALL_TABLES, ma questo flag funziona solo per le tabelle transazionali.

Per questi motivi, l’SQL_MODE che ho deciso di utilizzare per scrivere le Stored Routine dei progetti STK è il seguente:

SET @@session.SQL_MODE = 'ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ONLY_FULL_GROUP_BY,STRICT_ALL_TABLES,STRICT_TRANS_TABLES';

Qui troverete una lista di tutti i flag di SQL_MODE in MySQL.

Un’altra ottima pratica è attivare lo Strict Mode di InnoDB, ma questo esula dagli scopi di questo post.

A presto!

Le entità di XML e HTML

English version

Come tutti dovrebbero sapere, alcuni caratteri devono essere sostituiti con delle entità, se si desidera usarli come testo in un documento XML o (X)HTML. Ad esempio, siccome i tag sono circondati dai caratteri < e >, non si può scriverli così come sono e aspettarsi di vederli apparire nella finestra del browser insieme al resto del testo.

Per inserire i caratteri che hanno un significato speciale, di solito si usano le entità. XML ha cinque entità predefinite, che sono presenti anche in HTML:

& &amp;
< &lt;
> &gt;
” &quot;
‘ &apos;

Per ottenere un risultato corretto, i caratteri & devono essere sostituiti prima degli altri.

Questi caratteri sono gli unici che potrebbero confondere il client e invalidare un documento. Nei parametri si può perfino lasciare < e >. Negli altri contesti, è possibile usare ” e ‘.

Si può tranquillamente evitare di sostituire gli altri caratteri “strani” utilizzando il set di caratteri UTF-8.

Nei documenti XML, è anche possibile evitare di utilizzare le entità predefinite, purché i caratteri corrispondenti appaiano solo nelle sezioni CDATA. La sintassi di CDATA è:

<![CDATA[ bla bla bla ]]>

Le sezioni CDATA non possono contenere la sequenza di caratteri ]]> e non vi è modo di aggirare questa restrizione.

Divertitevi!