[RUBY] [Rails] Je veux tout réinitialiser car les données de l'environnement local sont incorrectes! Que faire avant ça

introduction

J'ai vu l'article Qiita suivant.

L'idée de couper l'original lorsque l'erreur n'est pas résolue \ -Qiita

Je voudrais que vous lisiez l'article ci-dessus pour plus de détails, mais dans un simple résumé, "Si les données dans l'environnement local deviennent étranges, recréons la base de données (après avoir confirmé que vous pouvez effacer les données)" est.

Cependant, j'ai personnellement pensé: "Eh bien, ce n'est pas si bon", alors j'ai décidé d'écrire un commentaire de réponse. Quand j'ai commencé à écrire des commentaires, cela devenait assez long, j'ai donc décidé d'en faire un article indépendant. C'est cet article.

C'est pourquoi je veux tout réinitialiser car les données de l'environnement local sont étranges! Voici ce que vous devez faire avant de réfléchir.

Je veux tout réinitialiser car les données de l'environnement local sont étranges! Que faire avant ça

(Remarque: Le contenu suivant a été écrit à l'origine comme un commentaire de réponse à l'article Qiita au début. Veuillez lire sur cette hypothèse)

La réinitialisation de la base de données est efficace lorsque «il est possible d'effacer toutes les données», mais elle ne peut pas être utilisée autrement. Les applications Rails développées comme passe-temps personnel peuvent convenir, mais les applications Rails développées au travail sont souvent dans un environnement local car elles contiennent beaucoup de "données de test que j'ai souvent utilisées". Cela signifie: "Je ne peux pas effacer tout cela." En outre, si le même problème se produit dans l'environnement de production au lieu de l'environnement de développement, la stratégie «d'effacement de toutes les données» ne peut pas être utilisée.

En outre, il devient difficile de rechercher la cause de la raison pour laquelle les données à l'origine de l'erreur se sont produites si toutes les données ont été effacées.

Pour les raisons évoquées ci-dessus, «l'effacement de toutes les données» ne doit vraiment être laissé qu'en dernier recours, et autant de recherches et d'actions que possible doivent être menées avant d'effacer les données.

Je prendrais les remèdes suivants.

Recherchez la cause du défaut et déterminez si les données sont anormales ou non.

Tout d'abord, déterminez la cause du problème. Dans cet article, il semble que la cause soit que «post.user» soit «nul».

Déterminez ensuite si la condition est raisonnable. Lorsque «post.user» est «nil», cela signifie qu'aucun contributeur n'est associé à la publication. D'un point de vue commun, je pense que c'est une situation improbable (= données anormales).

Rechercher la cause de l'erreur de données et corriger le code si nécessaire (prévention de récidive)

Ensuite, pensez à la cause: "Pourquoi un message sans affiche est-il sorti?" Si vous ne trouvez pas la cause, même si vous recréez la base de données et n'obtenez aucune erreur, après un certain temps, «messages sans affiches» peut réapparaître.

Si vous utilisez normalement l'écran et que vous pouvez publier sans poster, c'est un bogue, assurez-vous donc de modifier le code pour que l'affiche soit définie de sorte que le bogue ne se reproduise pas.

Les causes possibles et les remèdes sont énumérés ci-dessous.

ʻOptional: if true` est attaché

Dans les Rails récents, l'enregistrement associé défini par appartient_to est requis par défaut, donc je pense que c'est peu probable, mais s'il a ʻoptional: true, supprimez-le. De cette façon, si vous essayez de sauvegarder un message avec ʻuser in nil, vous obtiendrez une erreur de validation.

app/models/post.rb

 class Post < ApplicationRecord
-  belongs_to :user, optional: true
+  belongs_to :user
 end

Si vous ajoutez plus tard la colonne ʻuser_id` à la table des articles

Ou peut-être que le modèle Post a été créé en premier, puis, quelque temps plus tard, une autre migration a ajouté ʻuser_id` à la table posts. Dans ce cas, après avoir exécuté la migration, il est nécessaire d'associer un enregistrement utilisateur à l'enregistrement Post existant et de le sauvegarder (modifier les données existantes). Si vous oubliez cette correspondance, vous vous retrouverez avec des "messages sans affiches".

Si l'enregistrement utilisateur a été supprimé

La cause la plus probable est peut-être "J'ai supprimé l'enregistrement utilisateur de l'affiche après avoir créé l'enregistrement de publication". dans ce cas,

• Les enregistrements d'utilisateur avec des enregistrements de publication associés ne peuvent pas être supprimés
• Ou, si vous supprimez l'enregistrement utilisateur, supprimez également l'enregistrement de publication associé.
• Ou, après avoir accepté un message sans poster comme données normales, un affichage comme "Utilisateur désabonné" est affiché à l'écran.

Une telle méthode d'adaptation peut être envisagée. Les deux premiers peuvent être définis avec l'option «dépendante» de Rails. Consultez les articles suivants pour plus de détails.

Différence entre: depend: restrict \ _with \ _ error et: restrict \ _with \ _exception \ -Qiita

C'est la seule cause qui me vient à l'esprit, mais si je trouve une autre cause (= défaut) que "c'était la cause", je modifierai le programme pour que les "messages sans affiches" ne soient plus créés à l'avenir.

Si des mesures de prévention des récidives sont prises, corriger les données anormales existantes

Une fois que vous avez créé une situation dans laquelle des données étranges ne sont pas créées, il est temps de corriger les données anormales existantes. Par exemple, vous pouvez définir l'affiche pour "Articles sans affiches" en exécutant le script suivant. (Ceci n'est qu'un exemple, veuillez donc modifier le script comme il convient.)

user = User.first
Post.all.each do |post|
  if post.user.nil?
    post.user = user
    post.save!
  end
end

Alternativement, la modification des données telle que la suppression de «messages sans affiches» est également une option.

Post.all.each do |post|
  if post.user.nil?
    post.destroy!
  end
end

En faisant cela, l'affiche sera liée à tous les messages, donc appeler post.user.image_name ne devrait pas provoquer d'erreur.

Si les données ne sont pas anormales, corrigez le code de manière appropriée

Si la situation où "il n'y a pas de contributeur associé à la publication" n'est pas un problème (valable comme spécification), il est nécessaire de séparer le traitement de la vue selon que "post.user" est "nul".

<% if post.user %>
  <%#Traitement lorsqu'il y a une affiche%>
<% else %>
  <%#Traitement lorsqu'il n'y a pas d'affiche%>
<% end %>

Résumé

Si vous le traitez de cette manière, vous n'aurez pas à prendre la mesure d '"effacer toutes les données". Ou plutôt, je pense qu'il est généralement approprié d'adopter cette approche, sauf lorsque vous dites: "Je le fais simplement dans mon environnement local comme passe-temps personnel."