PDO non mi garba quasi niente - Parliamone

[skidx]

A me non sembra abbiano fatto un bel lavoro, mi piacerebbe discuterne con voi, se vi va.

Punto 1.
Sembra mancare totalmente un metodo per sapere il numero di righe restituite da una SELECT, cioè il corrispondente del mysql_num_rows().
Il metodo rowCount() restituisce il numero di affected_rows() (tranne in alcuni casi, dove "some databases may return the number of rows returned", quindi non è affidabile per questa funzionalità).

Punto 2.
Manca un metodo per eseguire SELECT "buffered" (quelle eseguite con mysql_query() ) senza passare per prepare() -> execute().
Infatti:
- la funzione exec() restituisce le affected_rows e non un resultSet, quindi è inutilizzabile per le SELECT;
- la funzione query() fa in pratica il corrispondente di una mysql_unbuffered_query() in quanto "If you do not fetch all of the data in a result set before issuing your next call to PDO::query(), your call may fail."
Quindi non si possono fare due SELECT diverse una dietro l'altra senza prima "scaricare" l'intero resultSet della prima.
- l'unica soluzione rimasta per una "buffered query" sembra essere quella di usare prepare() e poi execute(), ma il vantaggio principale di questi metodi si presenta quando va ripetuta una stessa query più volte (con parametri diversi). Per eseguire query diverse in sequenza io la trovo molto sconveniente: primo perché la mia query può non avere parametri di cui fare l'escape, secondo perché essere costretti a due chiamate di funzione per ogni query mi sembra una cosa inutilmente macchinosa, terzo perché il dialogo client/server (dove il client è il php e il server il DBMS) è inutilmente appesantito.

A me sembrano due mancanze importanti, se non ci mettono una pezza è assai probabile che io eviti di usarlo per questi due motivi.
Che ne pensate?

[andr3a]

Punto 1
uso PDO da tempo e non ho mai avuto questa necessità seppur credo sia effettivamente una mancanza ... sempre usato una var integer e incrementata in ciclo

Punto 2
Manca un metodo per eseguire SELECT "buffered" (quelle eseguite con mysql_query() ) senza passare per prepare() -> execute().
già ... puoi fare una cosa tipo questa però che risolve il count, il buffered e la singola linea per la chiamata

foreach($db->query($query) as $row[]){}

l'unica soluzione rimasta per una "buffered query" sembra essere quella di usare prepare() e poi execute(), ma il vantaggio principale di questi metodi si presenta quando va ripetuta una stessa query più volte (con parametri diversi).

non necessariamente, il vantaggio principale è anche ordinare la query ed asicurarsi l'impossibilità di sql injections invece di dover usare mysql_escape_string o mysql_real_escape_string per ogni dato di ogni query.
Poi se consideri che prepare ed execute sono 2 classi distinte (la prima PDO, l' altra PDOStatement) credo sia normale dover fare una chiamata in più ... ma una linea di codice anche breve come $smtp->execute() dici che incide così tanto per il PHP ??? :master:



essere costretti a due chiamate di funzione per ogni query mi sembra una cosa inutilmente macchinosa, terzo perché il dialogo client/server (dove il client è il php e il server il DBMS) è inutilmente appesantito.

appesantito ??? una riga da 10 caratteri su un driver compilato ? ...



A me sembrano due mancanze importanti, se non ci mettono una pezza è assai probabile che io eviti di usarlo per questi due motivi.
Che ne pensate?

penso che per queste 2 sole mancanze comunque raggirabili sia una presa di posizione un po' forzata quella di scegliere di non usare un driver che ti permette di scrivere una sola volta un applicativo e di poterlo utilizzare su qualunque database (perchè è per questo che è nato PDO).
Questa sua caratteristica ti riduce del 300% lo sviluppo di forum, blogs, guest, quello che ti pare, qualora volessi fare un applicativo portabile ... solo le query saranno diverse e non tutte le chiamate a funzioni dedicate, oltre alle query.

Questo vantaggio, unito al fatto che un domani potrebbero eliminare queste mancanza, essendo PDO giovane, credo lo renda la soluzione più indicata, tanto più quando tutti gli altri linguaggi hanno drivers analoghi e questo per PHP è nato proprio per colmare questo bastone tra le ruote in fase di sviluppo crossplatform.

Opinioni personali ovviamente


P.S. se invece sviluppi solo per un database, puoi usare quel solo driver che ti interessa, peccato per SQLITE3 che senza PDO non va (almeno così mi sembra di ricordare) , gli altri li conosci

[skidx]

Originariamente inviato da andr3a
sempre usato una var integer e incrementata in ciclo

Che è un'altra cosa. Io voglio sapere quante righe sono PRIMA di scorrere i risultati. E non c'è modo.

già ... puoi fare una cosa tipo questa però che risolve il count, il buffered e la singola linea per la chiamata

foreach($db->query($query) as $row[]){}

Come ben sai, quello è un ciclo.
Ora, secondo me eseguire N iterazioni (con N arbitrario) di un ciclo per fingere una normalissima buffered_query a me sembra una cosa eccessiva, pesante, e anche brutta a vedersi

non necessariamente, il vantaggio principale è anche ordinare la query ed asicurarsi l'impossibilità di sql injections invece di dover usare mysql_escape_string o mysql_real_escape_string per ogni dato di ogni query.

Come ho scritto poi, la mia query può non avere dati di cui fare l'escape, e quindi essere costretto a un prepare() -> execute() diventa inutile.

appesantito ??? una riga da 10 caratteri su un driver compilato ? ...

Ho scritto "il dialogo client/server". Questo perché la prepare(), sui database che supportano la funzionalità, fa precompilare la query al DBMS e poi passa i parametri tramite execute(). Quindi lo scambio di informazioni tra PHP e database aumenta. Questo è un vantaggio se devo eseguire la stessa query più volte, diventa uno svantaggio se devo farlo una sola volta.

tanto più quando tutti gli altri linguaggi hanno drivers analoghi e questo per PHP è nato proprio per colmare questo bastone tra le ruote in fase di sviluppo crossplatform.

Non è il concetto del PDO che non mi piace, chiaramente, anzi ben venga. E' questa particolare implementazione che non mi convince, per i punti sopra illustrati.
Si poteva fare la stessa cosa un po' meglio, secondo me. Così ne frenano l'utilizzo loro per primi. Manca il modo nativo di eseguire due delle funzioni più usate del database più usato.

[andr3a]

Come ben sai, quello è un ciclo.
come un ciclo è quello interno alla buffered, anche se "non lo vedi", come potresti sapere altrimenti il totale dei risultati ?


Ora, secondo me eseguire N iterazioni (con N arbitrario) di un ciclo per fingere una normalissima buffered_query a me sembra una cosa eccessiva, pesante, e anche brutta a vedersi
sul while non fai N interazioni con N arbitrario ?
se esci prima non devi fare un free_result piuttosto che un unset($row) del mio esempio ?
cosa c'e' di preciso di eccessivo e pesante in una sola linea di codice che ti risolve il problema ?


sarà che da anni uso sempre mysql_unbuffered_query (notoriamente più veloce) e ripeto non ho mai avuto un problema (quindi l'esempio foreach l'ho sfornato su 2 piedi, mai usato) ma tutto questo "dramma" non lo vedo, e se proprio mi sforzo vedo un piccolo cavillo raggirabile contro la valanga di vantaggi nell' usare questo layer.

Come ho detto, punti di vista

[daniele_dll]

skid ... il numero di righe è si comodo saperlo ma ci sono modi alternativi

purtroppo non tutti i RDBMS/DBMS prevedono questo quindi loro non possono implementarlo a priori

tornando al numero di righe ... io faccio questo che trovo ancora è veloce e leggero rispetto al count

$query = bla bla bla;

$rowCount = 0;
while($row = pdo_fetch_function($query))
{
$rowCount ++;
}

if ($rowCount == 0)
{
// butti fuori il codice che avvisa dei risultati non trovati o fai quello che devi fare
}

in questo modo ottieni l'identico stesso risultato senza però forzare il sistema a conteggiare le righe (cosa molto pesante dato che deve scorrere l'intera tupla e sei quindi costretto ad avere le query bufferizzate (vuol dire che deve trasferire TUTTO alla prima esecuzione, invece magari non è detto che a te serva gestire tutti i risultati estratti)

comunque personalmente a me pdo non piace nemmeno, ma non per qualche motivo riguardante il funzionamento ma per il fatto che hanno provato a imbrigliare un DAL (Database Abstraction Layer [quindi non un Query Abstraction Layer]) dentro php ... comportando un totale stravolgimento:
- pdo è si compilato ma è un'estensione e se ci sta un bug è quindi IMPOSSIBILE aggiornarla [i venditori di hosting aggiornano ogni secolo] quindi effettivamente o si usa su un server dedicato o se si becca un bug si ci attacca al tram o si cercano temporanei workaround
- pdo è (a parer mio) strutturato non benissimo, ci potrebberò essere delle cose da migliorare qua e la e soprattutto manca, cosa per me fondamentale, la possibilità di implementare un motore di astrazione per le query!!!

Tempo addietro, quando lavoravo con gianko, avevamo sviluppato un layer di astrazione che non si occupava SOLO di interfacciarsi con i vari database ma anche di riscrivere le query appositamente per i vari database partendo dal dialetto di mysql e per quello che mancava veniva tutto gestito a runtime durante il fetch ... forse pesante (ma comunque erano cose che servivano all'applicativo) però riduceva i tempi di sviluppo e testing in modo IMPRESSIONANTE!

Se dovevo prendere e portare un'applicativo su DB2 ci stavo pochissimo! Mi bastava implementare la conversione del dialetto mysql in quello di db2 e implementare ciò che mancava in un misto tra sql e php ... riducendo i tempi di sviluppo

ora ... ripeto non sono soluzioni ottimali per la performance ma dipende in che ambito sei, riscrivere metà della logica di un'applicativo non è fattibile e queste soluzioni sono fondamentali!

[skidx]

Originariamente inviato da andr3a
Come ben sai, quello è un ciclo.
come un ciclo è quello interno alla buffered, anche se "non lo vedi", come potresti sapere altrimenti il totale dei risultati?

La struttura restituita dal database quando c'è una "buffered" query (nel caso del mysql in pratica viene fatta una store_result() dopo la query)contiene già il numero delle righe. Non c'è bisogno di ulteriori cicli.
L'unico "ciclo" è quello che fa il database quando crea la struttura con i risultati della query.

E il ciclo fatto dal DBMS è un po' diverso dal ciclo fatto in PHP, in termini di prestazioni.

[andr3a]

Originariamente inviato da skidx
E il ciclo fatto dal DBMS è un po' diverso dal ciclo fatto in PHP, in termini di prestazioni.

si ma sempre ciclo è (solo che non lo vedi ... e il foreach lavora incore, non è un while o un for con espressione dinamnica da valutare ...) ... comunque insisto, io non ho mai avuto il problema di dover avere a tutti i costi mysql_num_rows e come ho già scritto (ma daniele al solito legge una riga su 50 ) ho sempre fatto esattamente come ha detto daniele

Originariamente inviato da andr3a
Punto 1
uso PDO da tempo e non ho mai avuto questa necessità seppur credo sia effettivamente una mancanza ... sempre usato una var integer e incrementata in ciclo

... l' esempio foreach era per toglierti 3 fastidi in una linea di codice, il count, che su indici numerici vorrei sapere quanto sia pesante ... , le due chiamate prepare e fetch e la possibilità di fare altre query dentro il for in lettura ...



[edit]
daniè ... c'e' scritto che PDO non ha alcuna intenzione di essere un layer astratto di sintassi ... e sinceramente preferisco così piuttosto che niente.
Per la questione bugs ... è giovane ma io lo uso da parecchio, mai un problema, porting per PHP4 compreso, in compenso consegno lavori PHP5.1 ready, se il loro host aggiorna, io non devo fare niente

[skidx]

Originariamente inviato da andr3a
si ma sempre ciclo è

Bon, vi mettete a spaccare il capello in quattro per ottimizzare anche le virgole, e poi mi rifilate che fare un ciclo in codice compilato e ottimizzato (quello del DBMS) è come farlo in PHP... sarà

Aldilà dei punti di vista, grazie per le vostre opinioni, il thread l'ho fatto proprio per questo.

[andr3a]

Originariamente inviato da skidx
Bon, vi mettete a spaccare il capello in quattro per ottimizzare anche le virgole, e poi mi rifilate che fare un ciclo in codice compilato e ottimizzato (quello del DBMS) è come farlo in PHP... sarà

forse non parlo bene l'italiano ... io non ho mai usato ne avuto il bisogno di usare quel foreach poichè non ho mai avuto necessità di utilizzare qualcosa come mysql_num_rows, essendo abituato da anni a sfruttare $a = 0 ed $a++ dentro il while(@$b = mysql_fetch_row($q)) su unbuffered_query ... quindi non "mettermi in codice" qualcosa che non ho mai fatto, l' ho solo scritto per i motivi che ho già descritto, per farti uno spunto su come risolvere una problematica, per farti un favore, ma dimentico sempre che non accetti consigli / soluzioni alternative o spunti.

Detto questo, le funzioni del PHP sono in C, compilate in C tanto quanto, presumo, un RDBMS ... che quest' ultimo faccia un ciclo interno ottimizzato o che il PHP lavori nel core a me cambia poco e non penso incida così spaventosamente ma ripeto, non userei mai quella soluzione se non in rarissime eccezioni... mai capitate fino ad ora.

Questo 3D, in questi termini, è inutile, perchè tu reputi essenziale mysql_num_rows e dici che usare execute() sia pesante per il server (fai dei tests e dacci i risultati, io li ho già fatti e sono stato pienamente soddisfatto *** ), noi (o almeno io) no, e trovo lo scrivere execute() nei pochi casi dove non mi serve aggiungere variabili automaticamente "escapate", una cosa stra-sormontabile, dati tutti gli altri vantaggi che PDO da rispetto a qualunque driver finora presente.

Come possiamo continuare ?



*** benchmarks in fondo a questa pagina:
http://wiki.grusp.it/index.php/PDO_Introduzione_all'_estensione_per_PHP_5.1

[skidx]

Originariamente inviato da andr3a
per farti un favore, ma dimentico sempre che non accetti consigli / soluzioni alternative o spunti.

Andrea, ma hai le mestruazioni tutto il mese tu?
Stiamo discutendo normalmente (e ho appena scritto "Aldilà dei punti di vista, grazie per le vostre opinioni, il thread l'ho fatto proprio per questo.") e subito la butti sul personale, cosa c'entri non lo so, ma guarda che campi male tu così, azzannando ai coglioni tutti quanti non appena sorge una diversità di vedute.

Eccheccazzo.

Ora, se a te non si è mai presentata l'esigenza di fare due query consecutive senza prima scorrere il risultato della prima, buon per te, ma questa esigenza può esistere (altrimenti non esisterebbero query buffered e unbuffered, ci sarebbero solo le ultime), e da qui il mio problema.
Tu mi hai suggerito un possibile escamotage, io ho detto che non mi piace tantissimo, è il caso di offendersi o buttarla sul personale per questo?
Boh!

Lo devo scrivere più grande?
E vabbè, facciamolo:

"Aldilà dei punti di vista, grazie per le vostre opinioni, il thread l'ho fatto proprio per questo."