L’estensione MySQL verrà  rimossa da PHP?

venerdì 15 luglio 2011 - 12:02

di Claudio Garau

La notizia si è diffusa in seguito ad un intervento di Phillip Olson nella mailing list degli sviluppatori di PHP; il titolo del messaggio parla chiaro: “deprecating ext/mysql“, anche se dal contenuto della mail si evince la necessità  di privilegiare un approccio più “morbido” possibile all’importante (e drastica) proposta effettuata.

Già  dalle prime righe del messaggio si capisce che l’eventuale processo per l’eliminazione dell’estensione nativa di MySQL in PHP non potrebbe essere iniziato con la versione 5.4; l’obbiettivo sarebbe invece quella di cominciare a segnalarla da subito come deprecata nella sola documentazione, suggerendo nel contempo l’utilizzo di alternative come PDO o mysqli.

La documentazione dovrebbe poi integrare maggiori esempi relativi all’utilizzo delle estensioni da utilizzare in sostituzione, non solo nelle pagine dedicate ad esse, ma anche in quelle in cui vengono descritte le MySQL functions, così da proporne puntualmente le alternative.

Inizierebbe in questo modo un processo che potrebbe portare ad associare le notifiche E_DEPRECATED alle funzioni basate sull’estensione MySQL a partire dalla release 5.5 del linguaggio, fino alla possibile eliminazione nella da tempo promessa versione 6.

L’intenzione potrebbe quindi essere quella di convincere gli sviluppatori a mettere mano al proprio codice così da non dover intervenire in futuro per la risoluzione di problemi di retrocompatibilità .

Categoria: PHP e Open Source | Commenta

Commenti per L’estensione MySQL verrà  rimossa da PHP?

Se dovesse essere rimossa l’estensione MySQL da PHP non credo sia un grosso problema: attualmente ci sono un sacco di soluzioni alternative a MySQL, PostgreSQL in primis, che funzionano probabilmente anche meglio.

Negli ultimi tempi MySQL é rimasto un pò indietro rispetto ai concorrenti, e credo sia un’ottima cosa “obbligare” gli sviluppatori PHP ad usare un approccio più generico come potrebbe essere PDO.

# - Postato da Marco Lecce 15 luglio 2011 alle 12:20

@Marco Lecce: hai letto bene l’articolo?

# - Postato da Cesar 15 luglio 2011 alle 12:36

@Cesar

Credo di sì, perché?

# - Postato da Marco Lecce 15 luglio 2011 alle 12:39

@Marco Lecce

non c’entra nulla MySql cone rdbms ma si parla di deprecare le funzioni mysql da php lasciando mysqli e pdo

# - Postato da sunnny 15 luglio 2011 alle 12:53

Come al solito stanno facendo porcherie…allora già  che ci sono perché non rimuovono anche le estensioni a PostreSQL, Oracle, ecc.? Non conviene usare PDO visto che é generico? In compenso, invece di eliminare subito direttive inutili e potenzialmente pericolose come register_globals, safe_mode, ecc., continuano a mantenerle aspettando PHP 6. Stanno rovinando PHP invece di renderlo un degno concorrente di altri linguaggi.

# - Postato da Alexandro 15 luglio 2011 alle 12:57

si, ma infatti non mi sembra di aver parlato di MySQL come RDBMS. Mi riferivo a quanto scritto nell’articolo che qui riporto:

This is not a proposal to add errors or remove this popular extension.

Voleva essere un commento un pochetto in polemica, visto che negli ultimi tempi ho avuto un sacco di problemi con database MySQL di medie/grosse dimensioni.

# - Postato da Marco Lecce 15 luglio 2011 alle 12:59

MySql ha i suoi problemi (molti dei quali si possono ovviare con un buon design) ma non c’entra: un linguaggio come php deve supportare più driver possibili

Perché poi costringere a usare PDO? Se non c’é bisogno di astrazione é meglio usare l’estensione ad hoc

# - Postato da sunny 15 luglio 2011 alle 13:52

Perché poi costringere a usare PDO? Se non c’é bisogno di astrazione é meglio usare l’estensione ad hoc

Perché é scritto meglio, é ad oggetti, é più veloce ed incoraggia a scrivere codice più sicuro. Bastano?

# - Postato da davide 15 luglio 2011 alle 14:04

quoto davide tutta la vita!!

Aggiungo che fornisce un livello di astrazione fondamentale per manutenibilità , estendibilità , ecc.

# - Postato da Marco Lecce 15 luglio 2011 alle 14:50

Perché é scritto meglio, é ad oggetti, é più veloce ed incoraggia a scrivere codice più sicuro. Bastano?

E’ “a oggetti” e allora? Se devi programamre oop é pieno di classi per driver specifici oppure te la fai ad hoc

E’ più veloce? Posta dei benchmark. Non credo proprio sia più veloce, al contrario

Incoraggia a scrivere codice più sicuro. Veramente é il classico strumento che ti fa dimenticare la sicurezza perché epnsi faccia tutto quelal classe

Uso spesso PDO ma non inventiamo palle, se ti servono feature specifiche di un rdbms devi cmq tenere d’occhio le query che gli passi. Inoltre se stai su un progetto di una certa serietà  e devi cambiare tipo di db certo non ti salvi perché hai usato da subito pdo

# - Postato da sunny 15 luglio 2011 alle 15:17

@sunny benchmark, non sono ufficiali e sono solo i primi che ho trovato.
Usare funzioni pensate e scritte in OOP non significa programmare in OOP.
PDO si può usare egregiamente anche in modo procedurale, solo rispetto alle improved ha un unico modo di utilizzo, cioé non c’é un metodo per essere usato in procedurale e uno in OOP.
PDO ha l’enorme vantaggio che se cambi piattaforma non devi rivedere tutte le funzioni ma solo alcune query se il caso; o usare ODBC e comunque non vai molto oltre.
Se fai tutti in mysqli_ e devi passare che so a postgree devi cambiare tutte le funzioni di base, anche se esistono indubbiamente librerie con wrapper di funzioni già  pronte, tu ti fidi di queste?
Ci sono casi in cui un solo applicativo deve accedere a più piattaforme diverse, in questo caso solo l’astrazione ti aiuta a venirne a capo in modo elegante e sicuro.
Sul lavoro ho dovuto usare proprio PDO per intefacciarmi a database diversi sulla stessa applicazione e parlo di mysql e Oracle per i dati principali, e … Access per la migrazione dei dati da questo a MS SQL Server, insomma un casino.
Infine PDO mette in campo quei metodi di formazione delle query che danno un minimo di sicurezza in più ad una piattaforma, il PHP, che di sicurezza ne ha davvero poca.
Per esempio se lo usi a pieno con prepare() e bindParam() eviti di scrivere codice come questo:
$query = “SELECT * FROM users WHERE user=’”.$_POST['user'].”‘ AND pwd=’”.$_POST['pwd'].”‘”; che in giro ce n’é già  tanto.

M.

# - Postato da Marco Grazia 15 luglio 2011 alle 16:33

al solito dalle risposte si vede chi fa “spaghetti” code e chi programma seriamente.
chi programma seriamente usa PDO per gli ovvi motivi di sicurezza, scalabilita e velocita.
chi fa spaghetti code si lamenta e basta

# - Postato da blackout 15 luglio 2011 alle 16:40

@blackout

neanche ti rispondo visto che insulti inutilmente

@Marco Grazia

io uso PDO spesso infatti, rispondevo al commento che suggeriva di “forzare” l’utilizzo del solo PDO

Riguardo ai benchmark, lo so che non esistono di ufficiali (rispondevo all’asserzione certa che PDO é più veloce) anche perché é molto difficile effettuarli (troppi fattori da considerare). A livello di logica, pdo aggiunge un ulteriore livello di astrazione ma stiamo parlando di differenze minime.

L’esempio che fai tu con bindParam ecc, ovviamente lo puoi fare con mysqli ovviamente e con qualsiasi cosa supporti stored procedures. Lo stesso grado di sicurezza lo ottieni con pdo o con mysqli.

Non ho mai detto che bisogna preferire mysqli a priori, non bisogna preferire nulla a priori. Riguardo a una situazione tipo l’applicativo a cui lavorato, puoi usare PDO o dei wrapper, ma la sostanza é che visto le differenze nei comandi sql dei vari dbms in genere bisogna prevedere cmq di passare delle query mirate sapendo a quale piattaforma ti stai riferendo. In soldoni, PDO risolve alcuni problemi ma non solleva lo sviluppatore dal conoscere le differenze tra i dbms che, come saprai meglio di me, sono tante.

Tornando IT, affondassero pure ext/mysql. Non vedo il bsiogno di affondare le altre estensioni specifiche, tutto qua

# - Postato da sunny 15 luglio 2011 alle 17:29

un buon orm che ti astrae la struttura del db ma di permette di inserire codice sql quando necessario tipo activerecord o sequel per ruby.

# - Postato da sasuke 15 luglio 2011 alle 18:24

consiglio di dare un occhio a idiorme paris 2 orm molto leggeri per scrivere codice sql in php

http://j4mie.github.com/idiormandparis/

# - Postato da sasuke 15 luglio 2011 alle 20:36

Non conviene usare PDO visto che é generico?

Da quello che ho letto nella documentazione su php.net il rovescio della medaglia dei PDO é che avendo il pregio di essere molto “astratti” non permettono di sfruttare le funzionalità  più evolute del DBMS (tipo gli statements multipli)

http://ie.php.net/manual/en/mysqli.overview.php

# - Postato da Giampi 20 luglio 2011 alle 12:11

Sarei anche d’accordo sul rimuovere le estensioni MySQL ma serei ancora più d’accordo sulla rimozione delle estensioni di per TUTTI i database, compresa la libreria PDO, a favore di un vero meccanismo di compatibilità  che … onestamente … non capisco perché tutti hanno e noi no (Java = JDBC, .NET = ado.net ecc ecc ecc)

Direi che sarebbe quasi ora, ad oltre 10 anni dal lancio di php3 e considerando che da subito, o quasi, abbiamo avuto il supporto per i database, di smetterla di considerarli un estensione e non parte del linguaggio e sarebbe anche ora di implementare qualcosa capace di funzionare come interfaccia indipendente (senza le estensioni per il database specifico come accade ora con PDO) e compatibile con tutti;

Quello che mi rode é che ci sono riusciti tutti (Sun, Microsoft e via dicendo) pur quanto in tali aziende ci lavorino si molte persone ma in numero enormemente minore di quanti sono i programmatori che ruotano attorno al “progetto” php.

E che non ci riusciamo noi ? Beh … onestramente questo mi rode.

# - Postato da Stefano 24 settembre 2011 alle 14:08

Lascia un Commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

È possibile utilizzare questi tag ed attributi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>