Forstå Ruby on Rails ActiveRecord Valideringer

Data Er en stor ting, Men feil data kan være veldig veldig dårlig. Heldigvis, hvis Du Er En Ruby on Rails programmerer du har en fin API Av ActiveRecord validering hjelpere til din disposisjon.denne guiden er en utforskning av vanlige Og ikke så vanlig ActiveRecord valideringer i En gitt Ruby On Rails søknad. Bruk den til å holde databasene glade!

Hvorfor bruke valideringer?

for å sikre at bare gyldige data lagres i databasen. På toppen av clientside validering, modellnivå valideringer gir et ekstra lag med sikkerhet for alle og alle skjemafelt i En Ruby On Rails søknad.

du kan gi valideringer i en rekke nivåer, men alle har sine styrker og svakheter.

• Databasebegrensninger-Unike begrensninger på databasenivå tillater ingen dupliserte felt eller kolonner hvis du trenger. Dette kan gå mye dypere enn bare unikhet. dvs. Standardverdier, ikke-null begrensninger, områder, etc…
• Validering På Klientsiden – disse er nyttige visuelt og gir bedre brukeropplevelse, men er ofte mer upålitelige. Jeg vil nesten alltid gi en backup plan ved hjelp av denne tilnærmingen som man burde.
• Modellnivå ( Rails) – Hva vi snakker om nå!
• Controller Level (Rails) – Fristende å bruke, men vanskeligere å teste og vedlikeholde. Det er en konvensjon / beste praksis for å holde kontrollerne så lette som mulig.

når skjer validering faktisk?

Rett fra ruby on rails dokumentasjon:

Det finnes To Typer Aktive Postobjekter: De som tilsvarer en rad i databasen og de som ikke gjør det. Når du oppretter et nytt objekt, for eksempel ved hjelp av new – metoden, tilhører ikke dette objektet databasen ennå. Når du ringer save på det objektet blir det lagret i riktig databasetabell. Aktiv Post brukernew_record? instansmetoden for å avgjøre om et objekt allerede er i databasen eller ikke.

Å Opprette en Ny Aktiv Postklasse gir oss mulighet til å bruke ennew_record? metode for å finne ut alt dette.

class Article < ApplicationRecordend

ved å gjøre det kan vi trykke rails console for å finne prosessen.

$ 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

faktisk ringer save er det som forplikter det til databasen og bak kulissene skaper de nødvendige SQL uttalelser for å gjøre det. Som et resultat, valideringer kjøres vanligvis før du sender data til databasen helt.

følgende metoder envoke valideringer ved bruk:

• create

create!save

• save!

update update!

bang-versjonene (f.eks.save!) heve et unntak hvis posten er ugyldig. Ikke-bang-versjonene gjør det ikke: save ogupdate returnerfalse ogcreate returnerer bare objektet.

Metoder som hopper valideringer

Ved hjelp av noen av følgende vil hoppe valideringer helt. Bruk med forsiktighet på verdifulle data!

• 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. Validering hjelpere er en av de tingene som gjør meg varm og koselig når distribusjon av en ny app ut i naturen. Dette gir mye støtte for et stort spekter av data du kan samle inn fra klientsiden.

hver hjelper aksepterer et:on og:message alternativ. Disse alternativene definerer når valideringen skal kjøres og hvilken melding som skal legges til en errors samling hvis den mislykkes (du kan bruke disse til å injisere hva som er galt i visningene dine, slik at brukeren vet hva som skal endres / endres).

Det er massevis av valideringshjelpere, nedenfor er noen av mine mest brukte. Vennligst sjekk ut guiden på active record valideringer for flere brukstilfeller.

Bekreftelse

Nyttig for validering når to tekstfelt må ha samme oppføring. Tenk på en e-postbekreftelse for eksempel.

class User < ApplicationRecord validates :email, confirmation: trueend

Nå i visningen kan du ha to felt:

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

en gotcha her er at denne valideringen bare utfører hvis presence alternativet er satt til true i modellen også.

såUser modellen får en oppdatering:

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

Utelukkelse

hvis du trenger å reservere noen ord Eller sørge for at en gitt oppføring er unik bruk exclusion.

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

Legg merke til hvordan jeg brukte :message her også. Dette er gitt på alle validering hjelpere.

du kan også bruke inclusion på motsatt måte. Se docs for mer info!

Format

Formateringsstrenger er noen ganger ideelle for appen din. Du kan bruke regulære uttrykk i valideringer for å endre hva du er ute etter.

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

Lengde

jeg bruker denne hele tiden for å sette en begrensning på tegnlengden til et gitt felt.

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

føl deg fri til å tilpasse meldingene med:message her også. Følgende er alle tilgjengelige for å koble til for å tilpasse meldingen.

wrong_lengthtoo_longtoo_short

Eksempel

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

presence

dette er trolig den mest brukte hjelperen i min verktøypose. Tilgjengelighetskontroller at feltene ikke er tomme.

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

du kan også teste en tilknytning eksisterer på modeller

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

på motsatt modell kan du gjøre det samme med en fangst kalt inverse_of

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

unikhet

kanskje du vil ha unike brukernavn på appen din? Unikhet hjelper med det.

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

dette søker faktisk i User tabellen for eksisterende poster for å bestemme uniqueness

Du kan gå videre og begrenseuniquenessned til enscope.

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

Betingede Valideringer

noen ganger trenger du bare å validere innenfor gitte forhold. Du kan utføre conditionals ved hjelp av en tilnærming som følgende.

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

Trenger du å gruppere flere forhold? Du kan gjøre det

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

Tilpassede Metoder

noen ganger er hjelperne ikke nok, og du trenger kanskje noe mer tilpasset. Du kan lage dine egne metoder som gjor noen valideringer for du ruller deg selv.

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

Merk her validerer jeg denne metoden ved hjelp av :on alternativet som lar deg bestemme hvor du skal initialisere valideringen. I dette tilfellet valgte jeg :create.

Du kan også koble tilerrors samlingen som jeg må endre hvilke utganger på klientsiden hvis du trenger det. Vi har ikke :message på tilpassede metoder i dette tilfellet. Les mer om feil.

Endelige Ord

Forhåpentligvis har valideringer åpnet noen ideer for å gjøre appen din mer begrenset (på en god måte). Ved Hjelp Av Ruby on Rails og alle dens fasetter gjør det mulig for trygge data å legge inn en database som du selv velger. FRA csrf-tokens til validering på databasenivå, er det uendelige måter å forbedre appen din, kan forbli rolig om dataene som kommer inn.

Skamløs Plugg!

hvis du likte dette innlegget, har jeg flere videoer på YouTube og her på bloggen min. Vil du ha mer innhold som dette i innboksen din? Abonner på nyhetsbrevet mitt og få det automatisk.

Sjekk ut kurset mitt

☝ Lyst til å lære Ruby on Rails fra grunnen av? Sjekk ut mitt kommende kurs Kalt Hello Rails.