En el trabajo tenemos una tabla para guardar los ajustes que contiene esencialmente las siguientes columnas:actualización Prevenir a filas inexistentes
PARAMNAMEVALUE
La mayoría de las veces los ajustes nuevos se agregado, pero en raras ocasiones, se eliminan las configuraciones. Desafortunadamente, esto significa que cualquier script que haya actualizado previamente este valor seguirá haciéndolo a pesar de que la actualización dé como resultado "0 rows updated" y genere un comportamiento inesperado.
Esta situación fue recobrada recientemente por una falla de prueba de regresión, pero solo después de mucha investigación sobre por qué los datos en el sistema eran diferentes.
Así que mi pregunta es: ¿Hay alguna manera de generar una condición de error cuando una actualización da como resultado cero filas actualizadas?
Estas son algunas de las opciones que he pensado, pero ninguno de ellos son realmente tan deseable:
- PL envoltura/SQL, que da cuenta del error de actualización y se produce una excepción.
- No es ideal ya que no detiene a nadie/a que una secuencia de comandos realice una actualización manualmente.
- Un disparador en la mesa que arroja una excepción.
- Va en contra de nuestra política actual de eliminación progresiva de desencadenantes.
- Requiere el activador de actualización cada vez que se elimina una configuración y mantiene una lista de configuraciones obsoletas (si se realiza la exclusión).
- Puede tener problemas con la tabla de mutación (si se hace inclusión al consultar qué configuraciones existen actualmente).
¿Cómo puede una actualización de 0 filas conducir a la IS tuación de que los datos son diferentes? –
@TheNail La configuración en cuestión fue un retraso. En el código anterior, el valor se actualizaba y los datos incluían el retraso especificado. En el nuevo código, no fue así. Regresión de Ergo Exactamente lo mismo hubiera sucedido si la configuración estuviera controlando si alguna característica se activó o no. –