È incredibile quanto, il mio inconscio, sia protettivo nei miei confronti.Qualche giorno fa, ho perfino ventilato nel blog, di essere rimasto piacevolmente sorpreso per essere riuscito a installare il mio sito web su un servizio di hosting a bassissimo costo (5.99€ inclusa la registrazionde del dominio .net !).
Tutto pareva funzionare e, il mio inconscio, mi ha trattenuto dal fare un minimo di test un po' complessi. Ieri pomeriggio, finalmente, mi sono deciso a trovare una cavia per fare del testing e, subito, i nodi sono giunti al pettine.
Dopo circa dieci minuti di debugging, è apparso evidente che il DB online era privo di funzioni e store procedures...
Ah, dimenticavo! Questo post sarà piuttosto tecnico e, quindi, ne consiglio la lettura ai soli addetti ai lavori. Anzi, ripensandoci, non la consiglio a nessuno! beh forse ai masochisti...
Avevo notato che, la maggior parte dei servizi di hosting, permetteva di utilizzare solo MySQL e, quindi, per evitare seccature di compatibilità anch'io decisi di usarlo, fin dall'inizio, per il mio sito. Oltretutto non lo avevo mai usato e, questo, fu un ulteriore stimolo a provarlo.
Non so, negli ultimi anni, avevo lavorato molto con Oracle (ero addirittura amministratore!) e, forse per questo, database come MySQL, o anche postgresql, mi sembrano dei "balocchini".
In effetti, un amico esperto, mi aveva fortemente sconsigliato dall'usare MySQL; però pensavo che fosse un po' prevenuto nei confronti di MySQL e, visto che apparentemente lo usano tranquillamente per "soluzioni medie e medio/grandi", decisi di utilizzarlo comunque.
Ovviamente, provenendo da Oracle, vedere delle query sparse a giro per il codice non mi piaceva e, subito, decisi di utilizzare store procedure (chiamate routines in MySQL) e funzioni.
Immediatamente, il medesimo amico, passò dall'allarme giallo all'allarme rosso! "Le store procedure non funzionano in MySQL! Le hanno appicicate nell'ultima versione ma sono un imbroglio!" mi disse/scrisse (in un linguaggio più sobrio e tecnico!).
In effetti, rimasi estremamente sorpreso, nel constatare che la documentazione ufficiale era praticamente assente. Solo con grande fatica trovai degli articoli striminziti in blog dimenticati...
Comunque, con qualche tentativo, riuscii a farle funzionare e così pensai che, come al solito, questo mio amico fosse un po' troppo prevenuto verso MySQL.
Così arriviamo a oggi. Non so per quale motivo (visto che la versione del DB sul server in teoria le supporterebbe) ma le store procedures e funzioni non possono essere usate. Ho esplicitamente aperto un ticket per chiederlo e questa è stata la laconica risposta:
Vostra richiesta:
La vostra versione del DB MySQL supporta stored routines e functions?
Se sì, come è possibile inserirle nel DB?
Saluti,
KGB
Risposta del tecnico del Supporto di Primo Livello:
Gentile KGB, la ringraziamo per averci contattato.
Siamo spiacenti di informarla che non c'è supporto per le routines/functions sui nostri server DB.
Le auguriamo buona serata.
Adesso mi trovo quindi a decidere cosa fare:
- Eliminare tutte le SP dalla mia applicazione in maniera da poter continuare a usare l'hosting a basso costo
- Migrare su un diverso hosting service che supporti MySQL con SP
- Passare a postgresql e, una volta pronto, a un servizio di hosting, probabilmente molto più costoso, che supporti detto DB
Le funzioni sono usate direttamente (tipo "select myFunc(X) from Dual;") 14 volte: questo è il caso meno problematico in quanto basta espandere il codice della funzione nel mio codice php.
Le funzioni sono usate indirettamente (tipo nella clausola "where" di una select) 14 volte: questo caso, temo, sia più complesso; in genere dovrebbe essere sufficiente sostituire la funzione con la sua espansione (tipo, al posto di "where myFunc(Q.ID_N)=3" usare "where (select ... where ...)=3") ma non credo che filerebbe tutto liscio...
Inoltre 4 funzioni sono usate nel corpo di altre funzioni.
Le procedure le ho in genere usate solamente per raggruppare una serie di query logicamente collegate fra loro. 7 sono di questo tipo e non dovrebbero dare problemi. 2 hanno un minimo di codice ma non dovrebbe essere un problema simulare lo stesso codice in php.
Sfortunatamente 2 procedure sono piuttosto complicate (una richiama l'altra, usano un cursore...) e sembrerebbe piuttosto difficile simulare, efficientemente, lo stesso codice in php. Fortunatamente, a un'analisi più approfondita, ho scoperto che queste procedure non vengono utilizzate! Ho ricostruito la loro storia: create il 26 marzo ma, già il 30 avevo adottato una soluzione alternativa molto più semplice; una nota del 31 marzo mi autorizzava a eliminarle...
Immagino di averle conservate perché, data la carenza di documentazione, avere un esempio di SP per MySQL non banali che FUNZIONANO, mi avrebbe potuto fare comodo!
In definitiva il problema sono le funzioni usate in maniera indiretta: ho paura di introdurre qualche bug espandendole all'interno di altre query...
Ora non voglio partire a testa bassa a modificare il mio codice; voglio invece cercare di capire quale sia la soluzione migliore e, magari, anticipare le possibili problematiche in cui potrei imbattermi...
Insomma stasera deciderò: se in due giorni riesco a convertire tutte le SPs potrebbe valerne la pena... Ma non è solo un problema di tempo: le SP non erano un mio capriccio ma servivano a rendere il codice molto più pulito e mantenibile. Anzi, da questo punto di vista, rischierei di fare doppio lavoro andando a reinserirle se/quando passo a un altro DB...
Comunque ho ricontattato, un altro servizio di hosting che usa MySQL, per chiedergli se supportano le SP: io spero di sì... In questa maniera taglierei la testa al toro...
Suggerimenti??
Nessun commento:
Posta un commento