PDO non mi garba quasi niente - Parliamone

[riccardone]

Originariamente inviato da daniele_dll
preferisco implementare anche un layer di astrazione per le query e non solo per le funzioni del database

layer di astrazione per le query? cercare di azzeccare la conversione dei vari dialetti usati per ogni dbms, mah... mi sembra a dir poco macchinoso

... a volte non vi capisco proprio

a me pdo piace anche se l'ho scoperto oggi

[andr3a]

Originariamente inviato da skidx
Beh, noi stavamo dicendo proprio questo, che cioè talvolta non basta riscrivere solo le query, perché spesso anche altri pezzi del programma sono progettati in funzione di alcune caratteristiche del database.

quando hai una struttura a seconda di alcuni dati agisci di conseguenza su parti di codice utili solo per quella casistica o un insieme di casistiche, è tanto difficile fare la stessa cosa anche con PDo a seconda del DB scelto ? :master:


da che mondo e mondo la gente cerca di racchiudere quante più funzionalità possibili in un insieme di classi facilmnente manovrabili da una sola interfaccia per casistiche diverse (una a caso ... la Archive.class.php che fa i tar, gz, bz2 e zip)

Cosa c'e' di strano nel pensare anche con i database, casistiche singolari, particolari o dedicate ?

Forse è l'abitudine o la "paura" della novità, io ci sviluppo tutto da tempo ed anche concettualmente, oltr che strtturalmente parlando, di miglioramenti ne ho fatti e come.

Poi ognuno è libero di usare sempre e solo un tipo di DB nella vita utile del suo applicativo, allora che lasci perdere PDO, a me piace e soprattutto piace avere un'unica interfaccia a seconda del db, le query sono l'unico problema, il resto dell' eventuale porting è praticamente realtime, altro che mezz' ora ... niente proprio

in ultimo diventa un modello standard di utilizzo database, connessione, selezione db, gestione risultati etc etc ... una volta abituati, difficilmente tornerete indietro

[skidx]

Originariamente inviato da andr3a
è tanto difficile fare la stessa cosa anche con PDo a seconda del DB scelto ? :master:

La stessa difficoltà che ti ha impedito di leggere "per me ben venga PDO, a parte alcuni problemucci trovo che l'idea sia abbastanza positiva."

[andr3a]

Originariamente inviato da riccardone
layer di astrazione per le query? cercare di azzeccare la conversione dei vari dialetti usati per ogni dbms, mah... mi sembra a dir poco macchinoso

ma il bello è che parlano di un layer che se esistesse risolverebbe tutti i problemi di PDO, ovvero non devi nemmeno riscrivere le query

Originariamente inviato da skidx
La stessa difficoltà che ti ha impedito di leggere "per me ben venga PDO, a parte alcuni problemucci trovo che l'idea sia abbastanza positiva."

parlavo del "dover" fare cose dedicate per un tipo o un altro di DB ... nulla di diverso da quanto facciamo nel quotidiano quando stendiamo le nostre classi .. PDO la guidi, non è che devi usarla direttamente per forza .. anzi, io praticamente mai

[skidx]

visto che ci siamo, parliamo un po' di codice, magari potete darmi qualche idea.

Io al momento ho una classe che mi astrae il mysql, il metodo query è questo (la classe è derivata da mysqli) :

function query($query)  
{
  $this->queriesCount++;
  $this->queries[] = $query;
  $result = parent::query($query);
  if($this->error)
  {
    if(in_array($this->errno, $this->deadlockErrors))
    {
      if(!$this->openTransaction)
      {	
        $repeatTransaction = DB_TRANSACTION_RETRY - 1;
        while($repeatTransaction > 0 && $this->error)
        {
	  $result = parent::query($query);
          $repeatTransaction--;
        }
        if(!$this->error)
	return $result;
      }
      throw new DeadlockException( 'error:E_DEADLOCK_GENERIC', $this, array($this->transactionOwner, $this->error, $this->errno));
    }
    throw new SQLException('error:E_QUERY', $this, array($this->errno, $this->error, $query));	
  }
  else
    return $result;
}

Fa quello che dicevo prima, intercetta gli errori dovuti a deadlock e, se la query non era in una transazione, la riesegue in maniera trasparente al chiamante (se era una transazione, va rieseguita tutta la transazione da parte del chiamante, che intercetterà l'apposita eccezione).

Ora, nell'ipotesi di scrivere quella classa basata su PDO di cui parlavo poc'anzi:

io posso anche fare l'overloading del metodo query(), ma questo nel PDO è un metodo generico. In teoria dovrei poter fare l'overloading del metodo query del driver PDO_Mysql, ma questo non è possibile perché il driver non è accessibile direttamente.
Se invece inserisco questo mio codice nell'overloading del metodo query() della PDO, lo sto snaturando, perché quella roba così com'è va bene solo per MySQL.

Quindi sono un po' bloccato su questa cosa...
Mi servirebbe una forma affinché la mia classe derivata del PDO mantenga la sua funzione di "interfaccia di tutti i driver specifici", ma allo stesso tempo voglio poter implementare quel tipo di logica perché nello specifico serve per la mia applicazione.
Consigli?

Pensavo a qualcosa del tipo:
- salvo il driver nel costruttore
- nella query(), se il driver è mysql faccio quella roba, altrimenti passo dritto.
Non lo so, non sono molto convinto... :master:

[daniele_dll]

Originariamente inviato da riccardone
layer di astrazione per le query? cercare di azzeccare la conversione dei vari dialetti usati per ogni dbms, mah... mi sembra a dir poco macchinoso

non c'è nulla da azzeccare ... bastano un set di regexp per quelle funzionalità che hanno una corrispondenza nel dialetto di destinazione altrimenti, oltre alla regexp, è necessario giocare pure all'estrazione dei dati

ma come ti ho detto è fondamentale perché altrimenti vorrebbe dire cambiare la logica del software ... e sinceramente ... non sempre è fattibile (ripercussioni e possibili bug o costi)

---

antré ... scriviti un layer di astrazione per le query, oltre che per db, e quando ti installerai DB2 o SyBase o Oracle ... sul tuo pc e cambiarai una manciata di parametri per la configurazione e vedrai andare tutto ... capirai cosa vuol dire goduria assoluta

(oltre al fatto che vedrai veramente quanto tempo risparmiato ... e facendo i test ti accorgerai che, siccome effettivamente le query che vengono astratte sono si e no il 20%/25% del totale le performance saranno comunque elevate)

[riccardone]

Originariamente inviato da daniele_dll
ma come ti ho detto è fondamentale perché altrimenti vorrebbe dire cambiare la logica del software ... e sinceramente ... non sempre è fattibile (ripercussioni e possibili bug o costi)

Mi hai detto che per te e' fondamentale, ok. Per come la vedo io scrivere da 0 un "layer di astrazione di query sql" e' l'ultimo dei miei pensieri per vari motivi.
Primo, perche' ne esistono gia' scritti e se quindi dovessi seguire quella di strada mi interesserei all'utilizzo ad esempio di orm e compagnia bella dove effettivamente puoi concentrarti sul domain model e pensare quasi solo in termini di oggetti disinteressandoti del'accesso e della persistenza concreta dei dati.
Secondo, perche' ci sono design pattern universalmente riconosciuti (un accenno l'ho indicato in estrema sintesi nel post precedente) che permettono di layerizzare l'applicazione in modo da rendere la scrittura di nuovi dal (pezzi di logica e non tutta la logica) un prezzo che si paga facilmente e con php5 mi sembra che finalmente si possano applicare appieno anche con questo linguaggio (interfacce, polimorfismo, incapsulamento e non tutto public ecc.).
Cmq, ho conosciuto programmatori con la p maiuscola che si sono addentrati in complesse funzioni per interpretare l'ininterpretabile quindi... de gustibus

[skidx]

... e approposito di pattern, php5, ereditarietà e polimorfismo, che ne dite di darmi una mano col problema descritto poco sopra?

[riccardone]

Originariamente inviato da skidx
che ne dite di darmi una mano col problema descritto poco sopra?

lo farei se solo avessi usato almeno una volta pdo il fatto e' che non sono neanche sicuro che l'hoster abbia la versione di php che lo contiene (se non sbaglio dalla 5.1 in poi mentre io ho a disposizione la 5.0.qualcosa). Cmq, guardando le varie funzioni pdo ti offre anche di gestire le transazioni quindi perche' non farlo fare a lui? perche' hai paura che davanti al primo deadlock si fermi? non potresti fare un wrapper alla funzione del pdo che simula il comportamento della tua classe e chiamare quello?

[skidx]

Originariamente inviato da riccardone
lo farei se solo avessi usato almeno una volta pdo il fatto e' che non sono neanche sicuro che l'hoster abbia la versione di php che lo contiene (se non sbaglio dalla 5.1 in poi mentre io ho a disposizione la 5.0.qualcosa). Cmq, guardando le varie funzioni pdo ti offre anche di gestire le transazioni quindi perche' non farlo fare a lui? perche' hai paura che davanti al primo deadlock si fermi?

No, aspetta, forse hai capito male.

Il deadlock viene segnalato dal database con alcuni specifici codici di errore. Normalmente quando una query dà errore si abortisce tutto e si logga / mostra a video il messaggio di errore, in quanto difficilmente l'applicazione può procedere se c'è un errore con il database.

Il deadlock invece è un errore "risolvibile". Se si presenta il deadlock, si ritenta la transazione (un massimo di X volte).
Ora, nella mia logica quindi ho bisogno di:
1) distinguere gli errori deadlock dagli altri errori, e questa è una cosa specifica del Mysql, perché negli altri database, se esiste il deadlock, ci saranno dei codici di errore diversi per segnalarlo.
2) quando il deadlock si presenta, sollevare una apposita eccezione.
Il metodo che aveva iniziato la transazione (con le apposite funzioni del PDO, certamente), che nel tuo schema sta proprio a livello DAL, intercetta l'eccezione specifica del deadlock, e si occupa di ritentare l'intera transazione.

Ora, il mio problema è più che altro di come strutturare la cosa secondo una "buona programmazione a oggetti".
La logica di gestione del deadlock andrebbe nel Driver Mysql, ma da questo driver non posso far ereditare nulla in PHP, è completamente mascherato da PDO.
Quindi mi ritroverei ad aggiungere funzionalità tipiche di uno specifico DBMS ad una classe che invece è proprio un'astrazione indipendente dai singoli DBMS. E quindi il mio problema "progettuale". Non so se mi sono spiegato.