2012-04-16 12 views
5

Al lavoro abbiamo un tavolo per contenere le impostazioni che contiene essenzialmente le seguenti colonne:aggiornamento Impedire alle righe inesistenti

  • PARAMNAME
  • VALUE

La maggior parte del tempo nuove impostazioni sono aggiunto, ma in rare occasioni, le impostazioni vengono rimosse. Sfortunatamente ciò significa che qualsiasi script che potrebbe aver precedentemente aggiornato questo valore continuerà a farlo nonostante il fatto che l'aggiornamento abbia come risultato "0 rows updated" e porti a un comportamento imprevisto.

Questa situazione è stata rilevata di recente da un errore del test di regressione, ma solo dopo molte indagini sul perché i dati nel sistema erano diversi.

Quindi la mia domanda è: C'è un modo per generare una condizione di errore quando un aggiornamento comporta l'aggiornamento di zero righe?

Qui ci sono alcune opzioni che ho pensato, ma nessuno di loro sono davvero tutto ciò che auspicabile:

  • PL involucro/SQL, che nota l'aggiornamento fallito e genera un'eccezione.
    • Non ideale in quanto non impedisce a nessuno/a uno script di eseguire manualmente un aggiornamento.
  • Un trigger sul tavolo che genera un'eccezione.
    • Contrasta con la nostra politica attuale di attivazione graduale dei trigger.
    • Richiede l'aggiornamento del trigger ogni volta che un'impostazione viene rimossa e mantiene un elenco di impostazioni obsolete (se si esegue l'esclusione).
    • Potrebbe avere problemi con la tabella di muting (se si esegue l'inclusione interrogando quali impostazioni esistono attualmente).
+0

Come può un aggiornamento di 0 righe portare alla sI che i dati sono diversi? –

+0

@ TheNail L'impostazione in questione era un ritardo. Nel vecchio codice il valore è stato aggiornato e i dati includevano il ritardo dato. Nel nuovo codice non lo era. Regressione ergo La stessa cosa sarebbe accaduta se l'impostazione controllasse se alcune funzionalità erano attive o meno. –

risposta

1

Non proprio una soluzione, ma un metodo per organizzare le cose un po ':

Creare un tavolo separato con le definizioni dei parametri e link a quella tabella dalla tabella valore del parametro. Stabilire il riferimento alla definizione del parametro richiesta (valori nulli non consentiti).

tabella di definizione PARAMS (ID, NAME)

impostazioni effettive tavolo PARAM_VALUES (PARAM_ID, VALUE)

(cambiando la struttura del tavolo è anche un modo molto efficace per evocare gli errori negli script che non sono stati aggiornati ...)

3

A PL/Il wrapper SQL sembra l'opzione migliore per me. I trigger sono una grande cosa da eliminare gradualmente, ad eccezione della generazione di sequenze e dell'inserimento di record di cronologia.

Se si è interessati all'aggiornamento manuale dell'utente anziché utilizzare il wrapper PL/SQL, limitare il ruolo utente in modo che non disponga dei privilegi UPDATE sulla tabella ma disponga dei privilegi EXECUTE sulla procedura.

1

Può essere che si può usare un'istruzione MERGE Ecco un link per esso

http://www.oracle-developer.net/display.php?id=203

La dichiarazione di unione consente di combinare inserimento e aggiornamento nella stessa query, quindi nel caso in cui la riga desiderata non lo fa esistono si può inserire un record in una tabella buffer per indicare la riga non esiste oppure è possibile aggiornare il record richiesto

Speranza aiuta

+0

Bella idea, ma questo ha lo stesso problema di un semplice aggiornamento in quanto richiede a qualcuno di notare che ci sono nuovi record nella tabella buffer. Se potevano notare questo, allora potevano facilmente notare le 0 righe aggiornate. Ma loro non lo fanno. Sto cercando di individuare la possibilità di un errore umano. –

Problemi correlati