PDO non mi garba quasi niente - Parliamone

[skidx]

Ci sarebbe anche un altro problema, su PDO e sulle diverse funzionalità dei vari driver.

PostgreSQL supporta le nested transaction, transazioni annidate. MySQL no.
MySQL non solo non le supporta, ma una seconda chiamata a START TRANSACTION causa l'implicito COMMIT della precedente, e questo, se non gestito, vuol dire casini.

A livello di astrazione dei dati, io posso avere due classi,
C1, e C2, ciascuna con un metodo insert().
Entrambi i metodi usano una transazione al loro interno.
Ma il metodo C1, dentro la propria transazione, crea un istanza di C2 e invoca C2::insert(), creando, senza saperlo (le classi servono proprio a nascondere l'implementazione interna) una transazione annidata, con relativo commit implicito e troiaio inatteso.
L'aspetto va quindi gestito ad uno strato inferiore, quello del database appunto, ma PDO non mi consente di farne una gestione specifica per ogni driver.

L'unica soluzione mi sembra quella di fare l'overloading dei metodi di PDO con dentro uno switch($driver) che esegue le opportune azioni in base al driver usato... non mi sembra una soluzione molto elegante però :master:

[andr3a]

Originariamente inviato da skidx
...
Ora, nell'ipotesi di scrivere quella classa basata su PDO di cui parlavo poc'anzi:
...

scusa ma li non ci sono query innestate ... fai sempre e comunque una query alla volta ... :master:

P.S. piccolo appunto, parli di overloading, mentre credo ti stia riferendo all' overriding

[riccardone]

Originariamente inviato da skidx
PostgreSQL supporta le nested transaction, transazioni annidate. MySQL no.
MySQL non solo non le supporta, ma una seconda chiamata a START TRANSACTION causa l'implicito COMMIT della precedente, e questo, se non gestito, vuol dire casini.

ma facendo un mysqldal per mysql e un pgdal per pg non riesci a cambiare appunto il comportamento in base alle specifiche necessita di ogni dbms? Entrambi i dal a chi li usa fanno vedere una funzione es. Insert (grazie magari all'utilizzo della medesima interfaccia) ma uno va via liscio (pg) e l'altro sta attento alle transazioni annidate.

[andr3a]

ma infatti tutta questa complessità non la vedo ... cmq un appunto vorrei farlo, magari scontato ...

non è che siccome uno sviluppa con PDO deve per forza fare l'applicativo cross-db, può anche usarlo semplicemente al posto di mysql pg sqlite o altri e sfruttarlo "normalmente" ... il vantaggio è che poi, qualora dovesse essere necessaria una versione anche per l'altro db, la manutenzione o i cambiamenti diventano sicuramente meno di quelli necessari a riscrivere il dal da zero ... solo a quel punto aggiungi o levi il check per la deadlock, per fare un esempio.

Insomma, a me come interfaccia piace, la uso per siti su mysql e non mi preoccupo, per ora, di fare per forza tutto cross-db(se il cliente cambia tutto paga l'aggiornamento) ma so comunque che:
1 - essendo nuovo, difficilmente verrà cambiato a breve, casomai verrà implementato
2 - esendo il layer astratto di riferimento, non dovrò preoccuparmi del driver che pilota quel o l'altro db, sarà lui a scegliere la giusta dll per me
3 - da oggi fino a penso 2 o 3 anni non dovrò preoccuparmi degli updates del server (anche grazie al mio porting per PHP4 compatibile con il 5 ed il 5.1), se metterà PDO, il sistema sarà più veloce, se non lo mette, lievemente più lento (non è compilato ma emulato) ma funzionerà comunque.

Sono queste le cose che mi piacciono, il resto sono problemi di routine per uno sviluppatore che hanno sempre una soluzione valida

[skidx]

Originariamente inviato da riccardone
ma facendo un mysqldal per mysql e un pgdal per pg non riesci a cambiare appunto il comportamento in base alle specifiche necessita di ogni dbms? Entrambi i dal a chi li usa fanno vedere una funzione es. Insert (grazie magari all'utilizzo della medesima interfaccia) ma uno va via liscio (pg) e l'altro sta attento alle transazioni annidate.

E il mysqldal che ne sa che c'è una transazione già aperta da un chiamante a monte?
Sono previsti i metodi per aprire e chiudere transazioni, non quelli per verificare la presenza o meno di transazioni aperte. L'unico è appunto tenere traccia di queste cose nella classe che astrae il database, che appunto deve avere comportamenti diversi a seconda del driver... con il piccolo problema che usando PDO io sul driver non ci posso mettere più mano.

Comunque il sonno porta consiglio, ho pensato un modo per scrivere il tutto che forse potrebbe andare abbastanza bene.
Poi magari lo posto e mi date un'opinione.

[daniele_dll]

comunque pdo è ancora BEN lontano di avere la maturità necessaria

è vero che è l'unica cosa che manca a php, però è anche vero che è ancora estremamente giovane e ci vorranno anni prima che queste lacune sia colmate

comunque, come dice anche il proverbio, chi fa da se fa per tre ^^

[skidx]

Originariamente inviato da daniele_dll
comunque pdo è ancora BEN lontano di avere la maturità necessaria

Questo lo dicono pure loro nelle note di release della 5.1, "mi raccomando, è ancora giovane, quindi pensateci bene prima di usarlo in una nuova applicazione" ... poi 3 righe dopo ti dicono che la vecchia estensione per Mysql non sarà abilitata di default a scapito del driver PDO_MYSQL... certo che son simpatici

[daniele_dll]

Originariamente inviato da skidx
Questo lo dicono pure loro nelle note di release della 5.1, "mi raccomando, è ancora giovane, quindi pensateci bene prima di usarlo in una nuova applicazione" ... poi 3 righe dopo ti dicono che la vecchia estensione per Mysql non sarà abilitata di default a scapito del driver PDO_MYSQL... certo che son simpatici

vabbe ... l'estensione di mysql nn è abilitata di default perché fa uso delle librerie di mysql

se abilitano quella di pdo di default vuol dire che non usano le librerie ma hanno scritto direttamente l'interfacciamento (cosa molto inteliggente per evitare tutti i problemi ... cosa che hanno fatto anche con perl e quasi tutti gli altri linguaggi)

e sarebbe cosa ancora più buona se lo facesserò anche con l'estensione attuale ^^

[skidx]

Originariamente inviato da daniele_dll
se abilitano quella di pdo di default

Boh, ti riporto il pezzo:

In PHP 4, MySQL 3 support was built-in. With the release of PHP 5.0 there were two MySQL extensions, named 'mysql' and 'mysqli', which were designed to support MySQL < 4.1 and MySQL 4.1 and up, respectively. With the introduction of PDO, which provides a very fast interface to all the database APIs supported by PHP, the PDO_MYSQL driver can support any of the current versions (MySQL 3, 4 or 5) in PHP code written for PDO, depending on the MySQL library version used during compilation. The older MySQL extensions remain in place for reasons of back compatibility, but are not enabled by default.

Tra l'altro, vorrei anche fargli i *complimenti* per aver invertito l'ordine dei parametri nelle funzioni mysqli_* rispetto a quelle mysql_*, un'altra genialata.

[andr3a]

Originariamente inviato da daniele_dll
comunque pdo è ancora BEN lontano di avere la maturità necessaria

è vero che è l'unica cosa che manca a php, però è anche vero che è ancora estremamente giovane e ci vorranno anni prima che queste lacune sia colmate

comunque, come dice anche il proverbio, chi fa da se fa per tre ^^

il mi oporting usa le estenzioni attuali / stabili e va su PHP4 come sugli altri ... per usarlo su PHP5.1 , qualora avessi paura, mi basterebbe scrivere new $_PDO piuttosto che new PDO

quindi ho fatto proprio da me, ho fatto per 3 ? :master: