Qual'è Il Modo Migliore Per Testare L'effettiva Connesione Al Db ?

International Italian
1

Sto provando questa strada




try {

            $this->db = new CDbConnection("pippo","pluto","paperino");    

        } catch (Exception $e) {

            $this->lastError = self::NQM_DB_ERROR;

        }

Il problema è che Yii genera comunque una Exception e non viene catchata

[quote

2013/03/29 10:35:12 [error] [exception.CDbException] exception ‘CDbException’ with message ‘CDbConnection failed to open the DB connection: invalid data source name’ in /data/var/www/clients/client0/web2/web/yii/framework/db/CDbConnection.php:381

[/quote]

2

trovato …

In realtà il codice NON SCOPPIA nel pezzo che ho copia/incollato.

Scoppiava una riga più in giu dove chiedevo lo status. E mi aspettavo che mi dicesse "not opened", non che cercasse di aprira, e quindi scoppiasse…

RISPOSTA



 try {


            $this->db = new CDbConnection( 'mysql:host=192.168.3.4;dbname=' . DB_DATABASE_NAME, DB_USERNAME, DB_PASSWORD);    


            $this->db->setActive(true);


        } catch ( Exception $e) {


            $this->lastError = self::NQM_DB_ERROR;


            return;


        }

Da documentazione del costruttore di CdbConection

3

Come mai hai sentito il bisogno di testare la connessione?

4

credo sia legato al discorso dell’installazione :D

5

ma a voi non capita nmai in produzione che un nodo db vada giu ?

6

No =).

7

buon per te.

Noi abbiamo un minimo di 4 nodi db (2 master + 2 slave) bilanciati e ridondati perchè un servizio è a dir poco vitale, e ad altisismo carico.

Se uno dei due nodi master (in scrittura) o slave(in lettura) và giu prima di una query, il php crasherebbe, se lasciato senza nessuna cura, incappando in una exception sollevata dal CDbCommand o dalla CDbConnection.

Dato che le query sono raggruppate per ovvie ragioni di performance, i test di disastery recovery e disaster survive, come li chiamo, vengono superati grandemente, e nessun dato perso.

Inutile dire, però, che a parte testare la connessione, yii non fa nulla in questi ambiti ‘estremi’, si va dritti di query

8

Con l’uso delle transazioni non risolvi il problema?

9

in caso di errore di connessione al db no, si genera comunque una eccezione

10

Scusami, ma la transazione non serve proprio a questo?

11

Anche qui, sensorario, ti esprimo solo il mio umile punto di vista. La mia esperienza è ancora limitata, però …

Prova a fare questo test (ed inorridirai come me la prima volta che l’ho notato)

Begin Transaction

Execute

Execute

Execeute (qui fai apposta qualcosa che la faccia fallire, inserisci un errore sql per esempio)

Commit

Vedrai, ed inorridirai, che Yii NON le gestisce bene le transazioni (o forse la colpa è di mysql sotto), in realtà se la terza SQl fallisce, il rollback delle prime due NON viene fatto.

Questo è un fattore, l’altro fattore è prestazionale. Ci vuole davvero meno (in termini di esecuzione, non di tempo di sviluppo) a usare mysqli a mano, piuttosto che passare per le transaction.

Dove le performance sono a dir poco vitali, l’ottimizzazione dei tempi passa quasi sempre da una strada mooooolto lontana ai framework, qualsiasi essi siano.

Fai un test diviso in tre parti fatto così

  1. 1000 insert query fatte tramite Yii::ap()->db->createCommand($sql)->execute();

  2. idem, ma incapsulandole in una transaction fatta da Yii

  3. un bel try…catch con dentro 1000 query fatte tramite la classe mysqli nativa di php

Purtroppo il codice nativo può essere anche 10 volte più performante rispetto al framework, ma questo è ovvio, scontato, naturale, comprensibile ed accettabile.

Semplicemente, comesviluppando un software in .NET le parti vitali talvolta si fanno in C++ a basso livello, così sviluppando in Yii le parti che necessitano di performance da paura si fanno a manina.

Yii è eccellente per agevolare la vita, ma alcune parti dell’applicazione, se si lavora sotto carichi (in termini di request http e di query) vanno quasi per forza fatte a mano.

12

se può esserti utile qui una situazione risolta, con transazioni e activerecord,

il codice sicuramente non terrà conto del caso in cui il db sia giù, magari potresti estendere activerecord

per i casi critici…

http://www.yiiframework.com/forum/index.php/topic/41044-risolto-transazioni-con-activerecord/

13

La butto li, … potresti provare a scrivere l’intero codice SQL della transazione ed eseguirla così.

PS. Credimi, io credo che tu abbia molta più esperienza di me. Io ho solo un po’ di punti nella hall of fame di questo sito, ma non farti ingannare =): vuole dire che ho più tempo libero.

14

Effettivamente sono 4 mesi che lavoro full time solo con Yii, ho già 3 progetti all’attivo, di cui il terzo, in corso, diventerà molto molto importante ed ha esigenze (vedi altri thread) particolari, al limite di yii.

Posso dire che ho già avuto modo anche di contribuire personalmente a Yii, YiiBooster, SwiftMailer e in altre librerie, tutte con le opportune pull-request accettate sui rispettivi github (il codice però l’han scritto ‘loro’ … )

ho creato componenti, estensioni, componenti che modificano altri componenti in modo da sopravvivere ai loro upgade, etc…

Si, sta diventando una cosa bellissima, è la prima volta che l’amore per un framework sopravvive a più di 10 giorni di lavoro ‘serio’.

… e si … io adoro programmare …

15

Idem, ed ora che stanno iniziando a chiudere issues tu yii2 sono anche un poco emozionato.