het begrijpen van Ruby on Rails ActiveRecord Validations

Data is een goede zaak, maar de verkeerde gegevens kunnen heel erg slecht zijn. Gelukkig, als je een Ruby on Rails programmeur hebt u een mooie API van ActiveRecord validatie helpers tot uw beschikking.

Deze gids is een verkenning van veel voorkomende en niet zo veel voorkomende ActiveRecord validaties in een gegeven Ruby on Rails applicatie. Gebruik het om uw databases tevreden te houden!

waarom validaties gebruiken?

om ervoor te zorgen dat alleen geldige gegevens in uw database worden opgeslagen. Bovenop clientside validatie, model-niveau validaties bieden een extra laag van beveiliging voor alle formuliervelden binnen een Ruby on Rails toepassing.

u kunt validaties leveren op verschillende niveaus, maar ze hebben allemaal hun sterke en zwakke punten.

• Databasebeperkingen-unieke beperkingen op databaseniveau maken het mogelijk om geen dubbele velden of kolommen te gebruiken als u dat wilt. Dit kan veel dieper gaan dan alleen uniciteit. dwz standaardwaarden, niet-nil beperkingen, bereiken, enz…
• client-side validation – deze zijn visueel nuttig en bieden een betere gebruikerservaring, maar zijn vaak onbetrouwbaar. Ik zou bijna altijd een back-up plan met behulp van deze aanpak als men zou moeten.
• Model Level (Rails) – waar we het nu over hebben!
• Controller niveau (Rails) – verleidelijk om te gebruiken, maar moeilijker te testen en te onderhouden. Het is een conventie / best-practice om je controllers zo licht mogelijk te houden.

wanneer vindt validatie daadwerkelijk plaats?

rechtstreeks uit de ruby on rails documentatie:

Er zijn twee soorten actieve Recordobjecten: objecten die overeenkomen met een rij in uw database en objecten die dat niet doen. Wanneer u een nieuw object maakt, bijvoorbeeld met behulp van de methode new, behoort dat object nog niet tot de database. Zodra u save op dat object aanroept, wordt het opgeslagen in de juiste database tabel. Actieve Record gebruikt denew_record? instance methode om te bepalen of een object al in de database zit of niet.

Het aanmaken van een nieuwe actieve Recordklasse geeft ons de mogelijkheid om een new_record? methode te gebruiken om dit allemaal uit te zoeken.

class Article < ApplicationRecordend

hierbij kunnen we rails console raken om het proces te lokaliseren.

$ 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

save is wat het commit naar de database en achter de schermen creëert de benodigde SQL statements om dit te doen. Als gevolg hiervan worden validaties meestal uitgevoerd voordat gegevens volledig naar de database worden verzonden.

De volgende methoden envoke validaties op gebruik:

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

De knal versies (bv. save!) verhogen een uitzondering als de record is ongeldig. De niet-bang versies niet: save en update return false, en create geeft alleen het object terug.

methoden die validaties overslaan

met behulp van een van de volgende methoden zullen validaties volledig overslaan. Wees voorzichtig met waardevolle gegevens!

• 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. Validatiehelpers zijn een van die dingen waardoor ik me warm en gezellig voel bij het inzetten van een nieuwe app in het wild. Dit biedt veel ondersteuning voor een groot scala aan gegevens die u kunt verzamelen van de client-side.

elke helper accepteert een:on en:message optie. Deze opties bepalen wanneer de validatie moet worden uitgevoerd en welk bericht moet worden toegevoegd aan een errors verzameling als het mislukt (u kunt deze gebruiken om te helpen injecteren wat er mis is in uw weergaven, zodat de gebruiker weet wat te veranderen/veranderen).

Er zijn een hoop validatiehelpers, hieronder zijn enkele van mijn meest gebruikte. Bekijk de gids over actieve record validaties voor meer use-cases.

bevestiging

nuttig voor het valideren wanneer twee tekstvelden dezelfde ingang moeten hebben. Denk bijvoorbeeld aan een e-mailbevestiging.

class User < ApplicationRecord validates :email, confirmation: trueend

in uw weergave kunt u nu twee velden hebben:

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

Eén Hebbes hier is dat deze validatie alleen werkt als de optie presence op true is ingesteld in het model ook.

dus het User model krijgt een update:

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

uitsluiting

Als u woorden wilt reserveren of ervoor moet zorgen dat een gegeven regel uniek is, gebruik exclusion.

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

merk op hoe ik :message ook hier gebruikte. Dit wordt verstrekt op alle validatiehelpers.

u kunt ook inclusion op de tegenovergestelde manier gebruiken. Zie de documenten voor meer info!

formaat

Opmaakstrings zijn soms ideaal voor uw app. U kunt reguliere expressies binnen validaties gebruiken om te veranderen wat u wilt.

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

lengte

Ik gebruik deze altijd om een beperking op de tekenlengte van een bepaald veld te plaatsen.

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

voel je vrij om de berichten ook hier te personaliseren met :message. De volgende zijn allemaal beschikbaar om haak in om het bericht aan te passen.

• wrong_length
• too_long
• too_short

Voorbeeld

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

Aanwezigheid

Dit is waarschijnlijk de meest gebruikte helper in mijn zadeltas. Presence controleert of de velden niet leeg zijn.

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

u kunt ook een associatie testen die bestaat op modellen

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

op het tegenoverliggende model kunt u hetzelfde doen met één catch genaamd inverse_of

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

uniciteit

misschien wilt u unieke Gebruikersnamen op uw app? Uniciteit helpt daarbij.

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

Dit zoekt eigenlijk in de User tabel voor bestaande records om uniqueness

te bepalen u kunt verder gaan en de uniqueness naar beneden beperken tot een scope.

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

voorwaardelijke validaties

soms hoeft u alleen te valideren binnen bepaalde voorwaarden. U kunt conditionals uitvoeren met behulp van een aanpak als de volgende.

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

meerdere voorwaarden groeperen? U kunt dat doen

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

aangepaste methoden

soms zijn de helpers niet genoeg en heeft u misschien iets meer aangepast nodig. U kunt uw eigen methoden die sommige validaties die u zelf rollen doen creëren.

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

opmerking hier Valideer ik deze methode met behulp van de optie:on waarmee u kunt bepalen waar de validatie geïnitialiseerd moet worden. In dit geval koos ik :create.

u kunt ook haak in deerrors collectie als ik moet wijzigen welke uitgangen aan de client-kant als je nodig hebt. We hebben in dit geval geen :message op aangepaste methoden. Lees meer over fouten.

Laatste Woorden

hopelijk hebben validaties een aantal ideeën voor u geopend om uw app beperkter te maken (op een goede manier). Met behulp van Ruby on Rails en al zijn facetten zorgt voor veilige gegevens om een database van uw keuze in te voeren. Van CSRF tokens tot database-niveau validaties, er zijn eindeloze manieren om uw app te verbeteren kan kalm blijven over de gegevens komen in.

schaamteloze Plug!

als je dit bericht leuk vond, heb ik meer video ‘ s op YouTube en hier op mijn blog. Wilt u meer inhoud zoals deze in uw inbox? Abonneer je op mijn nieuwsbrief en ontvang deze automatisch.

bekijk mijn cursus

☝ wil je Ruby on Rails van de grond af leren? Bekijk mijn komende cursus Hello Rails.