[MySQL] trovare dipendenze degli oggetti

[MarcusASP]

Salve a tutti,

sono nuovo di questo forum che mi è stato consigliato da un amico: m'ha detto che c'è tanta gente che potrebbe aiutarmi

Passo alla questione:
Se faccio una modifica ad un oggetto del DB, ad esempio aggiungo/rimuovo un campo da una tabella oppure cambio la firma di una stored-procedure o di una function (aggiungendo/togliendo un parametro o cambiandogli il tipo di dato), come posso fare per conoscere le dipendenze dell'oggetto che ho cambiato?
In altri termini, come faccio ad avere la lista degli oggetti che dovrei adeguare in forza della modifica che ho operato su un oggetto?
Di solito, le liste delle dipendenze elencano due liste:
1) lista degli oggetti che dipendono da un determinato oggetto
2) lista degli oggetti da cui un determinato oggetto dipende

A me basterebbe la prima delle due.

Magari c'è una query o un piccolo script-SQL già pronto da poter lanciare...

Spero nel vostro interessamento

[deleted_29]

non ho capito un granchè, ma così "a occhio" la risposta è...

non fai

[MarcusASP]

@franzauker

Mi spiace, pensavo di essermi spiegato a sufficienza. Magari dimmi cos'è che non ti è chiaro: cercherò di spiegarmi meglio.
La risposta, invece non è fra le più incoraggianti .
Forse solo chi ha la mia stessa esigenza può capirmi

@Tutti

Comunque, nel frattempo, ho provato a fare:

SELECT 
    SPECIFIC_NAME 
FROM 
    information_schema.ROUTINES 
WHERE 
        ROUTINE_DEFINITION LIKE CONCAT('%' , 'DBP_WRITE_EXCEPTION_INFO' , '%')
    AND 
        SPECIFIC_NAME <> 'DBP_WRITE_EXCEPTION_INFO';

dove 'DBP_WRITE_EXCEPTION_INFO' è il nome dell'oggetto di cui desidero cercare le dipendenze (eccesso sé stesso).
In effetti funziona perché mi ha risposto con la seguente lista:

DBF_GET_PARAMETER_NUMERIC
DBF_GET_USER_ATTRIBUTED_SESSION_ID
DBF_GET_USER_EMAIL
DBF_GET_USER_SESSION_ID
DBF_HAS_USER_SESSION_ID
DBF_IS_USER_IN_SESSION
DBF_NICKNAME_TO_USERID
DBF_USERID_TO_NICKNAME
DBP_ACTIVATE_USER
DBP_ASSIGN_PASSWORD_TO_USER
DBP_ASSIGN_USER_TO_USER_GROUP
DBP_INCREMENT_USER_LOGIN_FAIL
DBP_INVALIDATE_USER_SESSION
DBP_REMOVE_USER_FROM_USER_GROUP
DBP_RESET_USER_LOGIN_FAIL
DBP_SET_USER_EMAIL

Però non funziona sempre perché se l'oggetto compare in un blocco commentato del codice della stored-procedure o della function, me lo visualizza lo stesso.

Suggerimenti? Migliori soluzioni?

Attendo fiducioso

[deleted_29]

Originariamente inviato da MarcusASP
@franzauker

Mi spiace, pensavo di essermi spiegato a sufficienza. Magari dimmi cos'è che non ti è chiaro: cercherò di spiegarmi meglio.
La risposta, invece non è fra le più incoraggianti .
Forse solo chi ha la mia stessa esigenza può capirmi

La tua esigenza la capisco.
E' che non credo che esista il concetto di "dipendenza" (qualsiasi semantica gli attribuisci) in mysql


Potrei, tuttavia, sbagliare.

[MarcusASP]

Beh, non credo che il concetto di "dipendenza" possa avere molte semantiche. Si tratta semplicemente di stabilire "chi usa cosa e non può farne a meno per conseravare la propria integrità funzionale".

Ammettiamo che io abbia la stored-procedure S che usa il campo C della tabella T: nel momento in cui rimuovo dalla tabella T il campo C, la stored-procedure S, pur continuando ad esistere, non può più funzionare a dovere.

La stessa cosa non può dirsi per un indice di una tabella. Ammettiamo che io abbia una tabella T che ha un indice I costituito dal campo C. Se rimuovo l'indice I, la tabella T continua ad essere quello che era: magari vado incontro a problemi di performance durante la selezione e/o durante l'ordinamento dei dati, ma il tutto continua a funzionare senza particolari criticità.

Apprezzo le caratteristiche messe a disposizione da MySQL ma, rispetto al altri DBMS, rilevo delle piccole lacune. Capisco che, fra le attività del DBA, c'è anche quella di verificare gli impatti di una modifica e prendere i dovuti provvedimenti, ma la disponibilità di qualche automatismo o di qualche funzionalità che aiuta il DBA ad effettuare le verifiche, non guasterebbe affatto.
Visto e considerato che tali lacune sussistono, mi chiedevo se qualcuno avesse già "inventato" qualcosa per colmarle.

Da quanto riscontro, almeno in questo forum, ma anche googlando, pare che, fin'ora, nessuno abbia inventato qualcosa a riguardo .

[deleted_29]

Originariamente inviato da MarcusASP
Beh, non credo che il concetto di "dipendenza" possa avere molte semantiche. Si tratta semplicemente di stabilire "chi usa cosa e non può farne a meno per conseravare la propria integrità funzionale".

Ammettiamo che io abbia la stored-procedure S che usa il campo C della tabella T: nel momento in cui rimuovo dalla tabella T il campo C, la stored-procedure S, pur continuando ad esistere, non può più funzionare a dovere.

Certamente, ma a quanto mi risulta mysql non ha la minima idea di cosa succeda nella stored procedure S, e tantomeno è in grado di "capire" che hai tolto il campo C dalla tabella T, nè gli interessa più di tanto (anzi diciamo per nulla).

Almeno per quanto ne so.

Esistono degli RDBMS che lo fanno? Me li menzioni, per favore?

La stessa cosa non può dirsi per un indice di una tabella. Ammettiamo che io abbia una tabella T che ha un indice I costituito dal campo C. Se rimuovo l'indice I, la tabella T continua ad essere quello che era: magari vado incontro a problemi di performance durante la selezione e/o durante l'ordinamento dei dati, ma il tutto continua a funzionare senza particolari criticità.

Esattamente come sopra: mysql non lo sa, nè gli frega, del fatto che ci sia un indice o meno (* con due eccezioni. Una sono le FK innodb, l'altra è la necessità di avere una chiave primaria innodb sempre ed in ogni caso, se non è dichiarata esplicitamente ne viene messa una "occulta" autoincrementante, ma è legato alla metodologia di inserimento delle tuple e di ordinamento degli indici secondari).
E' un "tuo" problema, non "suo".

Apprezzo le caratteristiche messe a disposizione da MySQL ma, rispetto al altri DBMS, rilevo delle piccole lacune.

Ne ha caterve, di lacune.
Non proprio "piccole", a mio avviso.

Capisco che, fra le attività del DBA, c'è anche quella di verificare gli impatti (...)

Continuo ad essere un pochino dubbioso sul "come" potrebbe funzionare qualcosa del genere.

O si usa un case, o non vedo proprio come "qualcosa" possa comprendere la semantica ed il funzionamento, ad esempio, di una stored qualsiasi (=non generata da lui stesso).
La quale, seppur banale, può benissimo andare incontro perfino a criticità di HP.

Posso sempre sbagliare, eh?

[MarcusASP]

MySQL non è in grado di capire cosa succede nella stored-procedure perché non ne esegue alcuna compilazione, al massimo controlla la sintassi. In realtà memorizza tutto il codice della stored che sta fra BEGIN e END e lo esegue quando la stored viene richiamata. Sul fatto che se ne accorga, si ha evidenza quando la esegue: infatti ti segnala che non riesce a fare binding per il campo C (che cosè C? Una variabile che non hai definito? Un campo di una tabella? E di quale tabella?): in altri termini, quando se ne accorge è già troppo tardi!

Ti menziono due RDBMS che stanno attenti a queste "cosucce" ed il relativo comportamento.

MS SQL-Server: dalla versione 2005 compila le stored-procedure e si accorge se un oggetto (che sia il campo di una tabella, oppure una stored, oppure una vista ecc.) non è definito. Al contario, se togli un campo C dalla tabella T oppure cancelli una stored-procedure SP1 usata dalla stored-procedure SP2 non ti dice nulla, ma almeno ti offre la possibilità di verificare (prima di fare la cancellazione) quali sono gli oggetti che ne fanno uso. A quel punto è compito del DBA quello di andare ad "adeguare" di codice di ogni singolo oggetto impattato. Unico limite: la verifica delle dipendenze è circoscritta al database in cui l'oggetto risiede: infatti, in una stored-procedure posso far riferimento ad una tabella che si trova in un altro DB della stessa istanza del server; a quel punto, se chiedo la lista delle dipendenze di quella tabella, lui non mi dirà che è usata in una stored-procedure che si trova in un altro DB

Oracle: da quanto ne abbia memoria, compila le stored-procedure all'interno di entità chiamate "package". Se cambio la firma di una stored-procedure oppure faccio una ALTER di una tabella (togliendo un campo o modificandone il tipo di dato), all'atto di committare la ALTER, Oracle fa un controllo in tutti i pakage e "invalida" quelli che sono impattati dalla modifica effettuata; provvede infine a fornire una lista dei package invalidati, in modo che il DBA abbia modo di intervenire, al fine di adeguare il codice di ciascun oggetto impattato in ciascuno dei package sengalati.

E chiaro che la variazione della struttura di una tabella oppure la variazione della firma di una stored-procedure innesca quello che è un "mio" problema, ossia quello di sapere cos'è stato impattato dalla modifica che ho fatto e prendere i dovuti provvedimenti. Per questo motivo, la possibilbilità di disporre di un piccolo script SQL che fornisca l'elenco degli oggetti impattati, risulta particolamente utile. Non pretendo che l'adeguamento avvenga automaticamente, ma almeno qualcosa che possa agevolarmi il lavoro!

E' altrettanto palese che un semplice comando SQL-DML non ce la fa a fornire i risultati che mi aspetto, neppure usando moltissimi case: infatti ho parlato di un piccolo script SQL che, all'occorrenza, utilizzerebbe anche cursori e quant'altro necessario.
Per quanto riguarda il discorso della semantica c'è poco da considerare: basterebbe che lo script raccolga il codice di ciascun oggetto, rimuovesse le parti che sono a commento, estraesse i singoli comando SQL-DML, nonché le chiamate a stored-procedure o a function, e per ciascuno verficasse se viene usata una tabella o una stored-procedure (a seconda dell'oggetto di cui desidero avere informazioni sulle dipendenze). Non pretendo neppure che gli oggetti vengano disposti in modo gerarchico (del tipo, T viene usata da SP1 che a sua volta viene usata da SP2 che a sua volta viene usata da F1 ecc. ecc.).

Googlando ho trovato uno stumento shareware che, fra le altre cose, fa anche quel che a me serve (applicabile a MySQL, SQL-Server ed Oracle). Peccato che al primo tentativo di farlo funzionare abbia catturato un'eccezione non gestita

[deleted_29]

Originariamente inviato da MarcusASP
MySQL non è in grado di capire cosa succede nella stored-procedure perché non ne esegue alcuna compilazione(...)

E allora confermi la mia prima risposta.

MS SQL-Server: dalla versione 2005 compila le stored-procedure e si accorge se un oggetto (che sia il campo di una tabella, oppure una stored, oppure una vista ecc.) non è definito. Al contario, se togli un campo C dalla tabella T oppure cancelli una stored-procedure SP1 usata dalla stored-procedure SP2 non ti dice nulla(...)

Confermi la mia seconda risposta

Oracle: da quanto ne abbia memoria, compila le stored-procedure all'interno di entità chiamate "package". Se cambio la firma di una stored-procedure (...)

Vado a memoria, si limita a verificare se c'è stata una modifica della struttura della tabella (anzi dell'hash della struttura della tabella).
E lo fa "stupidamente": se aggiungo un campo, non succede nulla di male.

Per questo motivo, la possibilbilità di disporre di un piccolo script SQL che fornisca l'elenco degli oggetti impattati, risulta particolamente utile.

Non hai specificato se questo script "magico" esiste in oracle o MS SQL, ossia dandoti l'elenco degli oggetti "impattati".
Devo riconoscere che la merda-microsoft non la uso, mentre ho sostituito oracle da un 7 anni almeno, quindi potrei non essere "aggiornato".

...basterebbe che lo script raccolga il codice di ciascun oggetto, rimuovesse le parti che sono a commento, estraesse i singoli comando SQL-DML, nonché le chiamate a stored-procedure o a function, e per ciascuno verficasse se viene usata una tabella o una stored-procedure (...)

E' un riconoscitore.
Da quanto mi risulta (risposta 1) non esiste in mysql.

Per software di terze parti non ti so dire, mai dire mai.

---
Segnalo, in ogni caso, che le stored di mysql, storicamente, non sono mai servite a molto, anzi sono state inserite diciamo così "di malavoglia", man mano, per venire incontro ai "fanatici" di altri RDBMS, nei quali sono decisamente più complete.

Personalmente non le uso praticamente mai, visto che il protocollo delle connessioni mysql è talmente leggero (a differenza di tanti altri), non ci sono "veri" vantaggi nella stragrande maggioranza dei casi.

Se trovi qualche strumento "intelligente" postalo, è sempre una informazione in più

[MarcusASP]

Citazione: Originariamente inviato da MarcusASP MySQL non è in grado di capire cosa succede nella stored-procedure perché non ne esegue alcuna compilazione(...) E allora confermi la mia prima risposta.

Confermo in parte perché, come scritto, quando la stored-procedure la vai ad eseguire, MySQL si accorge che c'è qualcosa che non va e, come ripeto, è ormai troppo tardi!

Non hai specificato se questo script "magico" esiste in oracle o MS SQL, ossia dandoti l'elenco degli oggetti "impattati".

Non ho mai detto che Oracle o MS SQL-Server utilizzino uno scritp per fornire le informazioni inerenti le dipedenze di un oggetto: ho solo scritto che in qualche modo forniscono al DBA uno strumento per rilevare ciò che viene impattato o che verrebbe impattato dalla modifica di un altro oggetto. Mi dispiace che Oracle faccia questa verifica in modo così stupido: ovviamente se aggiungo un nuovo campo non impatto un bel niente!

E' un riconoscitore. Da quanto mi risulta (risposta 1) non esiste in mysql.

Beh, chiamarlo "risconoscitore" mi sembra esagerato. In ogni caso non ho mai parlato di qualcosa che MySQL mettesse già a disposizione: ho invece chiesto notizie in merito ad una soluzione per qualcosa che MySQL non mette a disposizione, infatti ho specificato fin da subito che avrebbe potuto essere necessario un piccolo script-SQL.
Chiaramente, qualora io riesca a giungere a soluzione, con le mie forze o mediante utility di terze parti, non mancherò di postare quando di utile io sarò riuscito a trovare.