förstå Ruby on Rails ActiveRecord Validations

Data är en bra sak men fel data kan vara väldigt mycket dåliga. Lyckligtvis, om du är en Ruby on Rails programmerare du har en trevlig API ActiveRecord validering hjälpare till ditt förfogande.

denna guide är en utforskning av vanliga och inte så vanliga ActiveRecord valideringar i en given Ruby on Rails ansökan. Använd den för att hålla dina databaser glada!

Varför använda valideringar?

för att säkerställa att endast giltiga data sparas i din databas. Ovanpå clientside validering, valideringar modellnivå ger ett extra lager av säkerhet för alla formulärfält i en Ruby on Rails ansökan.

Du kan tillhandahålla valideringar på olika nivåer men alla har sina styrkor och svagheter.

• databasbegränsningar-unika begränsningar på databasnivå tillåter inga dubbla fält eller kolumner om du behöver. Detta kan gå mycket djupare än bara unikhet. dvs. standardvärden, icke-nollbegränsningar, intervall etc…validering av klientsidan-dessa är användbara visuellt och ger bättre användarupplevelse men är ofta mer opålitliga. Jag skulle nästan alltid ge en reservplan med hjälp av detta tillvägagångssätt som man borde.
• Modellnivå (Rails) – vad vi pratar om nu!
• Controller Level (Rails) – frestande att använda men svårare att testa och underhålla. Det är en konvention / bästa praxis för att hålla dina kontroller så lätta som möjligt.

när sker validering faktiskt?

direkt från ruby on rails dokumentation:

det finns två typer av aktiva postobjekt: de som motsvarar en rad i din databas och de som inte gör det. När du skapar ett nytt objekt, till exempel med metoden new, tillhör det objektet inte databasen ännu. När du ringer save på det objektet sparas det i lämplig databastabell. Active Record använder instansmetodennew_record? för att avgöra om ett objekt redan finns i databasen eller inte.

att skapa en ny Active Record-klass ger oss en möjlighet att använda en new_record? metod för att räkna ut allt detta.

class Article < ApplicationRecordend

genom att göra så kan vi slå rails console för att hitta processen.

$ 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

att faktiskt ringa save är det som förbinder det med databasen och bakom kulisserna skapar de nödvändiga SQL uttalanden för att göra det. Som ett resultat körs valideringar vanligtvis innan data skickas till databasen helt.

följande metoder anger valideringar vid användning:

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

bang-versionerna (t.ex. save!) höj ett undantag om posten är ogiltig. De icke-bang versioner inte: save och update retur false och create returnerar bara objektet.

metoder som hoppar över valideringar

Om du använder något av följande kommer att hoppa över valideringar helt. Använd med försiktighet på värdefulla 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. Valideringshjälpare är en av de saker som får mig att känna mig varm och mysig när jag distribuerar en ny app ute i naturen. Detta ger mycket stöd för ett stort antal data som du kan samla in från klientsidan.

varje hjälpare accepterar ett :on och :message alternativ. Dessa alternativ definierar när valideringen ska köras och vilket meddelande som ska läggas till i en errors – samling om den misslyckas (du kan använda dessa för att injicera vad som är fel i dina vyer så att användaren vet vad som ska ändras/ändras).

det finns massor av valideringshjälpare, nedan är några av mina mest använda. Kolla in guiden om aktiva rekordvalideringar för fler användningsfall.

bekräftelse

användbar för att validera när två textfält måste ha samma post. Tänk på en e-postbekräftelse till exempel.

class User < ApplicationRecord validates :email, confirmation: trueend

nu i din vy kan du ha två fält:

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

en gotcha här är att denna validering endast utför om presence alternativet är inställt på true I modellen också.

såUser modellen får en uppdatering:

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

uteslutning

om du behöver reservera några ord eller se till att en viss post är unik användexclusion.

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

Lägg märke till hur jag använde :message här också. Detta tillhandahålls på alla valideringshjälpare.

Du kan också använda inclusion på motsatt sätt. Se dokumenten för mer info!

Format

Formateringssträngar är ibland idealiska för din app. Du kan använda reguljära uttryck inom valideringar för att ändra vad du än är ute efter.

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

längd

Jag använder den här hela tiden för att begränsa teckenlängden för ett givet fält.

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

Känn dig fri att anpassa meddelandena med :message här också. Följande är alla tillgängliga att ansluta till för att anpassa meddelandet.

• wrong_length
• too_long
• too_short

exempel

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

närvaro

detta är förmodligen den mest använda hjälpen i min verktygsväska. Närvaro kontrollerar att fälten inte är tomma.

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

Du kan också testa en association finns på modeller

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

på den motsatta modellen kan du göra detsamma med en fångst som heter inverse_of

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

unikhet

kanske vill du ha unika användarnamn på din app? Unikhet hjälper till med det.

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

detta söker faktiskt User tabell för befintliga poster för att bestämma uniqueness

Du kan gå längre och begränsa uniqueness ner till en scope.

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

villkorliga valideringar

Ibland behöver du bara validera inom givna villkor. Du kan utföra villkor med hjälp av ett tillvägagångssätt som följande.

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

behöver du gruppera flera villkor? Du kan göra det

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

anpassade metoder

Ibland räcker inte hjälparna och du kanske behöver något mer anpassat. Du kan skapa dina egna metoder som gör några valideringar du rullar själv.

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

notera här validerar jag den här metoden med :on alternativ som låter dig bestämma var du ska initiera valideringen. I det här fallet valde jag :create.

Du kan också ansluta tillerrors-samlingen eftersom jag måste ändra vilka utgångar på klientsidan om du behöver. Vi har inte :message på anpassade metoder i det här fallet. Läs mer om fel.

Slutord

förhoppningsvis har valideringar öppnat några ideer för dig att göra din app mer begränsad (på ett bra sätt). Använda Ruby on Rails och alla dess aspekter möjliggör säker data för att komma in i någon databas som du väljer. Från CSRF-tokens till valideringar på databasnivå finns det oändliga sätt att förbättra din app kan förbli lugn om de data som kommer in.

skamlös kontakt!

om du gillade det här inlägget har jag fler videor på YouTube och här på min blogg. Vill du ha mer innehåll som detta i din inkorg? Prenumerera på mitt nyhetsbrev och få det automatiskt.

kolla in min kurs

Hawaiian vill du lära dig Ruby on Rails från grunden? Kolla in min kommande kurs som heter Hello Rails.