[RUBY] [Rails6] concevoir + paranoïa + à la fois suppression logique utilisateur et contraintes uniques réalisées dans la série MySQL8

introduction

Dans l'environnement du titre, j'ai eu du mal à équilibrer la suppression logique de l'utilisateur et la contrainte unique. Je résumerai brièvement la solution. Il y avait un moyen de passer outre la contrainte unique de la conception et de lui donner sa propre contrainte. Tous sont le résultat de se demander s'ils sont gênants et plus faciles à faire.

Chose que tu veux faire

Dans l'environnement précédent (en particulier MySQL), effectuez une suppression logique au lieu de la suppression physique de l'utilisateur par défaut du périphérique, Et je veux sécuriser une contrainte unique afin qu'un utilisateur retiré puisse se réinscrire avec la même adresse et ID.

PostgreSQL, SQLite Il semble que ces deux bases de données puissent être facilement implémentées en utilisant l'index partiel. ・ Article de mise en œuvre ・ Add_index Specification 1 ・ Spécification Add_index 2

Il semble que cet index partiel n'est pas adopté par MySQL et ne peut être manipulé facilement. (Étant donné que l'information n'est que de 5,7, est-elle adoptée en série 8? De toute façon, cela semble impossible à partir de la migration des Rails) C'est peut-être légèrement anti-MySQL ...

Conclusion (méthode d'implémentation dans MySQL)

Je pense que vous pouvez lire cet article. https://vanhuyz.com/how-to-apply-unique-restriction-with-soft-delete-in-rails/

1. Après avoir ajouté la colonne deleted_at,
2. En donnant à supprimé_at une valeur spécifique pour l'utilisateur actif au lieu de Null Réalisez UNIQUE avec 2 colonnes (non réalisé si dollarted_at est NULL)
3. Suppression logique simple et contrainte unique

Merci beaucoup pour le meilleur article! !!

la mise en oeuvre

[environnement]

• Ruby：2.6.6p146
• Rails：6.0.3.3
• MySQL：8.0.21
• mysql2：0.5.3
• devise：4.7.2
• paranoia：2.4.2

Préparation

Comme il existe de nombreux autres articles sur la mise en œuvre de parties de base telles que la construction de l'environnement, la conception et l'introduction de la paranoïa, je les omettrai. Il est indispensable que la fonction standard d'inscription / retrait d'adhésion, etc. fonctionne.

1. Créez un fichier de configuration paranoia.rb

config/initializers/paranoia.rb

#Traitement pour obtenir à la fois une suppression logique et des contraintes uniques après le retrait de l'utilisateur
#Les enregistrements non supprimés sont supprimés_at = '0000-01-01 00:00:00'
#L'enregistrement supprimé est supprimé_at != '0000-01-01 00:00:00'
Paranoia.default_sentinel_value = DateTime.new(0)

2. Changement d'indice de la migration

Créer un fichier de migration qui modifie l'index de la table Users par défaut

rails g Change_Index_To_Users

Modifiez le fichier de migration créé comme suit

Supprimer l'index des e-mails une fois créé par défaut Créer un nouvel index unique avec [email, deleted_at]

db/migrate/202009220000000.rb

class ChangeIndexUniuqueToUsers < ActiveRecord::Migration[6.0]
  def change
    remove_index :users, :email
    add_index :users, [:email,:deleted_at], unique: true
  end
end

migration

rails db:migrate

3. Ajouter une validation

Ajout de la validation au niveau de l'application

app/models/user.rb

class User < ActiveRecord::Base
  acts_as_paranoid
  validates :email, uniqueness: { scope: :deleted_at }	

4. Contrôle de fonctionnement

Démarrez la console rails ou le serveur rails, créez un utilisateur, désabonnez-vous et réenregistrez-vous avec la même adresse pour vérifier la base de données.

Vous vous êtes réinscrit avec succès avec la même adresse! !! S'il vous plaît laissez-moi savoir s'il existe un autre bon moyen!