Understanding Ruby On Rails ActiveRecord Validations

Data on hieno asia, mutta väärät tiedot voivat olla hyvin pahoja. Onneksi, jos olet Ruby On Rails ohjelmoija sinulla on mukava API ActiveRecord validation helpers käytettävissänne.

tässä oppaassa tutkitaan yleisiä ja ei niin yleisiä ActiveRecord-validointeja tietyssä Ruby On Rails-sovelluksessa. Käytä sitä auttaa pitämään tietokannat onnellinen!

Miksi käyttää validointeja?

varmistaaksesi, että vain kelvolliset tiedot tallennetaan tietokantaasi. Clientside validationin lisäksi mallitason validoinnit tarjoavat ylimääräisen suojakerroksen kaikille Ruby On Rails-sovelluksen lomakekentille.

voit antaa validaatioita useilla eri tasoilla, mutta kaikilla on vahvuutensa ja heikkoutensa.

• Tietokantarajoitukset – uniikit rajoitteet tietokantatasolla eivät salli päällekkäisiä kenttiä tai sarakkeita, jos niin vaaditaan. Tämä voi mennä paljon syvemmälle kuin vain ainutlaatuisuus. esim. oletusarvot, ei-nollarajoitukset, vaihteluvälit jne…
• asiakaspuolen validointi-nämä ovat visuaalisesti hyödyllisiä ja tarjoavat paremman käyttökokemuksen, mutta ovat usein epäluotettavampia. Olin lähes aina tarjota varasuunnitelma käyttäen tätä lähestymistapaa kuin pitäisi.
• Mallitaso (kiskot) – Mistä nyt puhutaan!
• Ohjaintaso (kiskot) – houkutteleva käyttää, mutta vaikeampi testata ja ylläpitää. Se on yleissopimus / paras käytäntö pitää ohjaimet niin kevyt kuin mahdollista.

milloin validointi todella tapahtuu?

Straight from the ruby on rails-dokumentaatio:

aktiivisia Tietuekohteita on kahdenlaisia: niitä, jotka vastaavat tietokannassasi olevaa riviä ja niitä, jotka eivät. Kun luodaan uusi olio esimerkiksi new – menetelmällä, kyseinen olio ei vielä kuulu tietokantaan. Kun soitat save kyseiselle kohteelle, se tallennetaan asianmukaiseen tietokantataulukkoon. Aktiivinen tietue käyttää new_record? instanssimenetelmää selvittääkseen, onko olio jo tietokannassa vai ei.

uuden aktiivisen Ennätysluokan luominen antaa meille mahdollisuuden käyttää new_record? menetelmää tämän kaiken selvittämiseksi.

class Article < ApplicationRecordend

näin voimme lyödä rails console prosessin paikantamiseksi.

$ 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

itseasiassa kutsuminen save sitoo sen tietokantaan ja kulissien takana luodaan tarvittavat SQL lausunnot siihen. Tämän seurauksena validoinnit suoritetaan tyypillisesti ennen tietojen lähettämistä kokonaan tietokantaan.

seuraavat menetelmät herättävät validointeja käytön yhteydessä:

• create

create!save

• save!
• update

update!

Bang-versiot (esim.save!) korota poikkeus, jos tietue on virheellinen. Ei-bang versiot eivät: save ja update return false, ja create vain palauttaa kohteen.

menetelmät, jotka ohittavat validoinnit

käyttämällä jotakin seuraavista, ohittavat validoinnit kokonaan. Käytä varoen arvokasta tietoa!

• 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. Validointi auttajat ovat yksi niistä asioista, jotka saavat minut tuntemaan lämmin ja kodikas, kun otetaan käyttöön uusi sovellus luonnossa. Tämä tarjoaa paljon tukea suurelle joukolle tietoja, joita saatat kerätä asiakaspuolelta.

jokainen auttaja hyväksyy :on ja :message option. Nämä valitsimet määrittelevät, milloin validointi suoritetaan ja mikä viesti lisätään errors collection, jos se epäonnistuu (voit käyttää näitä auttamaan pistämään näkymiin, mikä on vialla, jotta käyttäjä tietää, mitä muuttaa/muuttaa).

validointiapulaisia on ton verran, alla muutamia käytetyimpiä. Tutustu oppaaseen aktiivisista tietueiden validoinneista saadaksesi lisää käyttötapauksia.

vahvistus

hyödyllinen validoinnissa, kun kahdessa tekstikentässä on oltava sama merkintä. Ajattele esimerkiksi sähköpostivahvistusta.

class User < ApplicationRecord validates :email, confirmation: trueend

nyt sinun mielestäsi voi olla kaksi kenttää:

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

yksi gotcha tässä on, että tämä validointi suoritetaan vain, jos presence vaihtoehto on asetettu todeksi myös mallissa.

siis User malli saa päivityksen:

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

poissulkeminen

Jos täytyy varata sanoja tai varmistaa, että tietty merkintä on yksilöllinen käyttää exclusion.

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

huomaa, miten käytin :message myös täällä. Tämä annetaan kaikissa validointiapulaisissa.

voit käyttää myös inclusion päinvastaisella tavalla. Katso docs lisätietoja!

formaatti

muotoilevat merkkijonot ovat joskus ihanteellisia sovelluksellesi. Voit käyttää säännöllisiä lausekkeita validaatioissa muuttaaksesi mitä haluat.

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

Pituus

käytän tätä koko ajan rajoittaakseni tietyn kentän merkkipituutta.

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

voit vapaasti muokata viestejä :message myös täällä. Seuraavat ovat kaikki käytettävissä kytkeä osaksi muokata viestin.

wrong_lengthtoo_longtoo_short

esimerkki

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

läsnäolo

tämä lienee työkalupakkini käytetyin apulainen. Läsnäolo tarkistaa, että kentät eivät ole tyhjiä.

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

assosiaatiota voi testata myös malleissa

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

vastapuolen mallissa saman voi tehdä yhdellä saaliilla, jonka nimi on inverse_of

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

ainutlaatuisuus

ehkä haluat uniikit käyttäjätunnukset sovellukseesi? Ainutlaatuisuus auttaa siinä.

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

tämä itse asiassa etsii User taulukko olemassa oleville tietueille uniqueness

voit mennä pidemmälle ja rajoittaa uniqueness alas a scope.

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

ehdolliset validoinnit

joskus täytyy validoida vain tietyissä olosuhteissa. Voit suorittaa conditionals käyttäen lähestymistapaa, kuten seuraavat.

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

tarvitseeko ryhmitellä useita ehtoja? Voit tehdä niin

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

Custom Methods

joskus auttajat eivät riitä ja saatat tarvita jotain customimpaa. Voit luoda omia menetelmiä, jotka tekevät joitakin validations rullata itse.

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

huomaa, että validoin tämän menetelmän käyttämällä :on – vaihtoehtoa, jonka avulla voit määrittää, missä validointi alustetaan. Tällöin valitsin :create.

voit myös koukuttaa errors kokoelmaan, koska joudun tarvittaessa muuttamaan mitä tuotoksia asiakaspuolella. Meillä ei ole :message mukautettuja menetelmiä tässä tapauksessa. Lue lisää virheistä.

Loppusanat

toivottavasti validoinnit ovat avanneet sinulle ideoita, joilla voit tehdä sovelluksestasi rajoittavamman (hyvällä tavalla). Ruby on Railsin ja sen kaikkien puolien käyttäminen mahdollistaa turvallisten tietojen syöttämisen mihin tahansa valitsemaasi tietokantaan. CSRF tokens tietokantatason validoinnit, on loputtomasti tapoja parantaa sovelluksen voi pysyä rauhallisena tietoja tulossa.

Shameless Plug!

Jos tykkäsit tästä postauksesta, minulla on lisää videoita Youtubessa ja täällä blogissani. Haluatko lisää tällaista sisältöä sähköpostiisi? Tilaa uutiskirjeeni ja saat sen automaattisesti.

Check out my course

☝ Haluatko oppia Ruby On Rails from the ground up? Tutustu tulevaan Kurssiini nimeltä Hello Rails.