Articoli taggati mysql
Parametro tmp dir MySQL, attenzione allo spazio
Feb 16
Qualora per motivi di spazio o banalmente convinti che la /tmp non sia necessario renderla di ampie dimensioni, potrebbe accadere che durante certe operazioni molto pesanti su tabelle con quantitativi di record notevoli, il sistema esaurisca lo spazio nella partizione temporanea durante la fase di elaborazione dati e scrittura di una tmp table, proprio su questa partizione.
La query abortira’ con un messaggio del tipo no space left on device o qualcosa del genere.
In tal caso andra’ allargata la partizione tmp di sistema (o dove si appoggia mysql) o in alternativa cambiato il path (che deve essere scrivibile dallo user “mysql“), fermato il servizio mysql e riavviato.
Potenziale SQL Injection con AdoDB e driver mysqli
Dic 29
[SEGNALO CHE HO SCOPERTO QUESTA COSA DA POCO E LIMITANDOMI AD ALCUNI TEST E PROVE VELOCI MA REALI, PERCUI OGNI EVENTUALE APPROFONDIMENTO/SMENTITA ETC... E' BEN ACCETTO]
Segnalo una problematica di sicurezza abbastanza importante per coloro che utilizzano adodb utilizzando il driver mysqli (le nuove funzioni di connessione con mysql native in php 5).
In sostanza le nuove funzioni mysqli consentono mediante la seguente funzione: mysqli_multi_query di poter eseguire più statement SQL in mysql come ad esempio:
SELECT * FROM TBL1 WHERE id = 1; DROP table TBL2;
Questa query utilizzando le vecchie librerie mysql (es. mysql_connect) dava errore.
La possibilità di eseguire più query SQL è supportata su mysql 5.0.x anche da command line, non saprei se anche vecchie versioni lo consentivano.
Questo significa che se per esempio utilizziamo in php una query del tipo:
$sql = “SELECT * FROM tbl1 WHERE id = $_GET['id']“; // (Premesso che venga come minimo fatto l’escape dei caratteri come ‘ o “)
Possiamo rischiare che qualche burlone passi in GET il seguente valore:
“1; DROP TABLE tbl2;”
Il che comporterebbe che l’SQL eseguito sia:
SELECT * FROM TBL1; DROP table TBL2;
Di fatto quindi con AdoDB con driver mysqli, la seconda query viene effettivamente eseguita.
Diventa quindi essenziale fare un controllo sull’input dell’utente per $_GET['id']. Ad esempio verificando che sia un numero intero.
La soluzione più rapida è quella di cambiare la connect di AdoDB dicendogli di usare il driver mysql anziché mysqli, la soluzione migliore e da fare comunque resta in ogni caso il filtraggio di tutti i dati in input.
MySQL 5.1 GA, attenzione a possibili bug fatali
Dic 3
Di seguito l’articolo in italiano di Punto Informatico:
http://punto-informatico.it/2494271/PI/News/mysql-51-una-falsa-partenza.aspx
E qui l’articolo ufficiale in lingua inglese di Michael Widenius ex CTO della mysql AB acquistata tempo fa da SUN.
http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html
Io per adesso rimango sul 5.0 sul quale onestamente ho avuto pochi problemi.
MySQL 5, utilizzo dei TRIGGER
Lug 11
Finalmente trovo il tempo di pubblicare un articolo…
Vediamo di seguito l’utilizzo dei TRIGGER in mysql 5, se non dico male infatti sino alla versione 5.0.x i TRIGGER su mysql non erano disponibili.
Prima di tutto, a cosa servono i TRIGGER? I TRIGGER hanno il principale scopo di automatizzare determinate operazioni sul database all’occorrenza di determinati eventi come INSERT, UPDATE o DELETE.
Il modo con cui creare un TRIGGER è piuttosto semplice:
CREATE TRIGGER setnoprice BEFORE UPDATE ON prodotto
FOR EACH ROW
BEGIN
IF NEW.online = ‘no’ THEN
SET NEW.prezzo = 0;
END IF;
END
Analizziamo cosa fa di fatto questo TRIGGER, al di là della sintassi:
Ipotizziamo di avere ad esempio un sito di e-commerce dal quale i prodotti sono acquistabili esclusivamente quando il loro prezzo è maggiore di zero, mentre sono online altri prodotti per il quale esiste una presentazione ma l’acquisto può essere fatto contattando l’ufficio commerciale e non viene esposto il prezzo.
Conseguentemente quando un prodotto va offline è automatico che non sia più vendibile. La soluzione più classica e semplice (apparentemente) è quella di gestire l’operazione direttamente da backoffice dell’applicativo in modo automatico o peggio ancora di delegare al gestore del backoffice il fatto di resettare a zero il prezzo quando un prodotto va offline.
[Piccolo inciso, so benissimo che potrebbe essere bloccato l'acquisto oltre che per prezzo a zero anche nel caso il flag online sia off, così come so che il prodotto non sarebbe nemmeno visualizzato, ma un'esempio lo dovevo fare...
]
Entrando nel dettaglio mysql applicando questo TRIGGER si preoccupa di eseguire PRIMA [BEFORE] dell’azione UPDATE [solo update quindi] la verifica se online diventerà uguale a off e in tal caso forza il nuovo valore di prezzo a zero.
In sostanza il TRIGGER va a sostituire quelle operazioni automatiche che normalmente vengono delegate all’applicativo.
Per maggiori informazioni potete consultare direttamente il manuale di mysql alla pagina relativa ai TRIGGER.
Convertire un database PostgreSQL in MySQL e viceversa
Mag 10
La conversione di un database PostgreSQL in mysql e viceversa non è un’operazione esattamente banale.
Nel senso che a differenza della conversione da SQL Server a mysql o da Access ad esempio, per i quali esiste il tool realizzato direttamente da mysql, mysql Migration Toolkit, per PostgreSQL questo software non ci aiuta.
Durante la ricerca di qualcosa di ben funzionante mi sono imbattuto in:
DB Convert for mysql and PostgreSQL 2.0.x
Questo software consente in modalità trial di importare solo 10 record per tabella. E’ sufficiente nel caso sia necessario solo ripristinare la struttura, nel caso import di dati invece risulta insufficiente.
Per poter disporre delle funzionalità complete è sufficiente acquistarlo ad una cifra ragionevole di 69 dollari.
Il software dopo l’installazione consente una comoda migrazione di tutto quanto. La migrazione può essere bidirezionale.
La stessa software house propone altri tool come il sync.
Sono disponibili inoltre migrazioni da svariati altri database.
Per maggiori informazioni: http://www.dbconvert.com
