Ruby on Rails ActiveRecord-Validierungen verstehen

Daten sind eine großartige Sache, aber die falschen Daten können sehr, sehr schlecht sein. Zum Glück, wenn Sie ein Ruby on Rails Programmierer sind, haben Sie eine schöne API von ActiveRecord Validierungshelfern zur Verfügung.

Dieses Handbuch ist eine Untersuchung der gemeinsamen und nicht so häufig ActiveRecord Validierungen in einem bestimmten Ruby on Rails-Anwendung. Verwenden Sie es, um Ihre Datenbanken glücklich zu machen!

Warum Validierungen verwenden?

Um sicherzustellen, dass nur gültige Daten in Ihrer Datenbank gespeichert werden. Zusätzlich zur clientseitigen Validierung bieten Validierungen auf Modellebene eine zusätzliche Sicherheitsebene für alle Formularfelder in einer Ruby on Rails-Anwendung.

Sie können Validierungen auf verschiedenen Ebenen bereitstellen, aber alle haben ihre Stärken und Schwächen.

  • Datenbankeinschränkungen – Eindeutige Einschränkungen auf Datenbankebene ermöglichen bei Bedarf keine doppelten Felder oder Spalten. Dies kann viel tiefer gehen als nur Einzigartigkeit. dh Standardwerte, Einschränkungen ungleich Null, Bereiche usw…
  • Clientseitige Validierung – Diese sind visuell nützlich und bieten eine bessere Benutzererfahrung, sind jedoch häufig unzuverlässiger. Ich würde fast immer einen Backup-Plan mit diesem Ansatz bereitstellen, wie man sollte.
  • Modellebene (Schienen) – Worüber wir jetzt sprechen!
  • Controller-Ebene (Schienen) – Verlockend zu bedienen, aber schwieriger zu testen und zu warten. Es ist eine Konvention / Best Practice, Ihre Controller so leicht wie möglich zu halten.

Wann findet die Validierung tatsächlich statt?

Direkt aus der Ruby on Rails Dokumentation:

Es gibt zwei Arten von Active Record-Objekten: solche, die einer Zeile in Ihrer Datenbank entsprechen, und solche, die dies nicht tun. Wenn Sie ein neues Objekt erstellen, z. B. mit der Methode new, gehört dieses Objekt noch nicht zur Datenbank. Sobald Sie save für dieses Objekt aufrufen, wird es in der entsprechenden Datenbanktabelle gespeichert. Active Record verwendet die new_record? Instanzmethode, um festzustellen, ob sich ein Objekt bereits in der Datenbank befindet oder nicht.

Das Erstellen einer neuen Active Record-Klasse gibt uns die Möglichkeit, eine new_record? -Methode zu verwenden, um dies alles herauszufinden.

class Article < ApplicationRecordend

Dabei können wir rails console drücken, um den Prozess zu lokalisieren.

$ rails console>> article = Article.new(title: "My Article")=> #<Article id:nil title: "My Article", created_at: nil, updated_at: nil>>> article.new_record?=> true>> article.save=> true>> article.new_record?=> false

Der eigentliche Aufruf von save verpflichtet es in die Datenbank und erstellt hinter den Kulissen die notwendigen SQL Anweisungen, um dies zu tun. Daher werden Validierungen normalerweise ausgeführt, bevor Daten vollständig an die Datenbank gesendet werden.

Die folgenden Methoden führen bei Verwendung zu Validierungen:

  • create
  • create!
  • save
  • save!
  • update
  • update!

Die folgenden Versionen (z. B. save!) lösen eine Ausnahme aus, wenn der Datensatz ungültig ist. Die Nicht-Bang-Versionen nicht: save und update Rückgabe false und create gibt nur das Objekt zurück.

Methoden, die Validierungen überspringen

Wenn Sie eine der folgenden Methoden verwenden, werden Validierungen vollständig übersprungen. Vorsicht bei wertvollen Daten!

  • decrement!
  • decrement_counter
  • increment!
  • increment_counter
  • toggle!
  • touch
  • update_all
  • update_attribute
  • update_column
  • update_columns
  • update_counters

Validation helpers

What I love about Ruby on Rails is the bundled goodness you get for doing pretty hard things. Validierungshelfer sind eines der Dinge, bei denen ich mich warm und gemütlich fühle, wenn ich eine neue App in freier Wildbahn bereitstelle. Dies bietet viel Unterstützung für eine Vielzahl von Daten, die Sie möglicherweise von der Clientseite sammeln.

Jeder Helfer akzeptiert eine :on und :message Option. Diese Optionen definieren, wann die Validierung ausgeführt werden soll und welche Nachricht zu einer errors Sammlung hinzugefügt werden soll, wenn sie fehlschlägt (Sie können diese verwenden, um zu injizieren, was in Ihren Ansichten falsch ist, damit der Benutzer weiß, was geändert / geändert werden muss).

Es gibt eine Menge Validierungshelfer, unten sind einige meiner am häufigsten verwendeten. Weitere Anwendungsfälle finden Sie in der Anleitung zur Validierung aktiver Datensätze.

Bestätigung

Nützlich zur Validierung, wenn zwei Textfelder denselben Eintrag haben müssen. Denken Sie zum Beispiel an eine E-Mail-Bestätigung.

class User < ApplicationRecord validates :email, confirmation: trueend

Jetzt können Sie aus Ihrer Sicht zwei Felder haben:

<%= text_field :user, :email %><%= text_field :user, :email_confirmation %>

Ein Problem dabei ist, dass diese Validierung nur ausgeführt wird, wenn die Option presence auch im Modell auf true gesetzt ist.

Das User Modell erhält also ein Update:

class User < ApplicationRecord validates :email, confirmation: true validates :email_confirmation, presence: true end

Ausschluss

Wenn Sie Wörter reservieren oder sicherstellen müssen, dass ein bestimmter Eintrag eindeutig ist, verwenden Sie exclusion.

class Profile < ApplicationRecord validates :username, exclusion: { in: %w(username1 username2 username3), message: "%{value} has already been taken." }end

Beachten Sie, wie ich :message auch hier verwendet habe. Dies wird auf allen Validierungshelfern bereitgestellt.

Sie können inclusion auch umgekehrt verwenden. Weitere Informationen finden Sie in den Dokumenten!

Format

Formatierungszeichenfolgen sind manchmal ideal für Ihre App. Sie können reguläre Ausdrücke in Validierungen verwenden, um alles zu ändern, wonach Sie suchen.

class Plan < ApplicationRecord validates :plan_type, format: { with: /\A+\z/, message: "Plans can only inlude letters"}end

Length

Ich benutze diese die ganze Zeit, um die Zeichenlänge eines bestimmten Feldes einzuschränken.

class User < ApplicationRecord validates :name, length: { minimum: 5 } # sets a minimum validates :bio, length: { maximum: 500 } # sets a maximum validates :handle, length: { in: 5..16 } # provide a rangeend

Sie können die Nachrichten auch hier mit :message personalisieren. Die folgenden sind alle zum Anschließen verfügbar, um die Nachricht anzupassen.

  • wrong_length
  • too_long
  • too_short

Beispiel

class User < ApplicationRecord validates :bio, length: { maximum: 800, too_long: "%{count} characters is the maximum." }end

Präsenz

Dies ist wahrscheinlich der am häufigsten verwendete Helfer in meiner Werkzeugtasche. Presence prüft, ob Felder nicht leer sind.

class User < ApplicationRecord validates :name, :email, presence: trueend

Sie können auch testen, ob eine Assoziation an Modellen vorhanden ist

class Article < ApplicationRecord belongs_to :user validates :user, presence: true # looks for a user_id field on the articleend

Beim gegenüberliegenden Modell können Sie dasselbe mit einem Catch namens inverse_of

class User < ApplicationRecord has_many :articles, inverse_of: :userend

Einzigartigkeit

Vielleicht möchten Sie eindeutige Benutzernamen für Ihre App? Einzigartigkeit hilft dabei.

class User < ApplicationRecord validates :username, uniqueness: true, { message: "Username already taken" }end

Dies durchsucht tatsächlich die User -Tabelle nach vorhandenen Datensätzen, um uniqueness

Sie können weiter gehen und die uniqueness auf eine scope.

class User < ApplicationRecord validates :plan, uniqueness: { scope: :year, message: "can only update one per year"}end

Bedingte Validierungen

Manchmal müssen Sie nur innerhalb bestimmter Bedingungen validieren. Sie können Bedingungen mit einem Ansatz wie dem folgenden ausführen.

class Purchase < ApplicationRecord validates :card_number, presence: true, if: :paid_with_card? def paid_with_card? payment_type == "card" endend

Müssen Sie mehrere Bedingungen gruppieren? Sie können das tun

class User < ApplicationRecord with_options if: :is_admin? do |admin| admin.validates :location, length: { minimum: 10 } admin.validates :job_title, presence: true endend

Benutzerdefinierte Methoden

Manchmal reichen die Helfer nicht aus und Sie benötigen möglicherweise etwas benutzerdefinierteres. Sie können Ihre eigenen Methoden erstellen, die einige Validierungen durchführen, die Sie selbst durchführen.

class Invoice < ApplicationRecord validate :active_subscriber, on: :create def active_customer errors.add(:customer_id, "is not active") unless subscriber.active? endend

Hinweis Hier validiere ich diese Methode mit der :on Option, mit der Sie bestimmen können, wo die Validierung initialisiert werden soll. In diesem Fall habe ich :create .

Sie können sich auch in die errors -Sammlung einbinden, da ich bei Bedarf die Ausgaben auf der Clientseite ändern muss. In diesem Fall haben wir nicht die :message für benutzerdefinierte Methoden. Lesen Sie mehr über Fehler.

Letzte Worte

Hoffentlich haben Validierungen einige Ideen für Sie geöffnet, um Ihre App (auf gute Weise) eingeschränkter zu machen. Mit Ruby on Rails und all seinen Facetten können sichere Daten in jede Datenbank Ihrer Wahl eingegeben werden. Von CSRF-Token bis hin zu Validierungen auf Datenbankebene gibt es endlose Möglichkeiten, Ihre App zu verbessern und die eingehenden Daten ruhig zu halten.

Schamloser Stecker!

Wenn Ihnen dieser Beitrag gefallen hat, habe ich weitere Videos auf YouTube und hier auf meinem Blog. Möchten Sie mehr Inhalte wie diese in Ihrem Posteingang? Abonnieren Sie meinen Newsletter und erhalten Sie ihn automatisch.

Schau dir meinen Kurs an

https://i.imgur.com/KIaaJEB.jpg

☝ Willst du Ruby on Rails von Grund auf lernen? Schauen Sie sich meinen bevorstehenden Kurs namens Hello Rails an.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.