compreender as validações ActiveRecord do Ruby on Rails

dados é uma coisa boa, mas os dados errados podem ser muito maus. Felizmente, se você é um programador Ruby on Rails você tem uma boa API de ajudantes de validação ActiveRecord à sua disposição.

Este guia é uma exploração de validações ActiveRecord comuns e não tão comuns em um dado Ruby on Rails aplicação. Use-o para ajudar a manter suas bases de dados felizes!por que utilizar validações?

para garantir que apenas os dados válidos são salvos na sua base de dados. Em cima da validação do cliente, validações de nível de modelo fornecem uma camada extra de segurança para todos e quaisquer campos de forma dentro de uma aplicação Ruby on Rails.

Você pode fornecer validações em uma variedade de níveis, mas todos têm suas forças e fraquezas.

• restrições da Base de dados – restrições únicas ao nível da base de dados não permitem campos ou colunas duplicados, se necessário. Isto pode ir muito mais fundo do que apenas singularidade. ou seja, valores por defeito, restrições não nulas, intervalos, etc…validação do lado do cliente – estes são úteis visualmente e proporcionam uma melhor experiência do usuário, mas muitas vezes são mais confiáveis. Eu quase sempre fornecia um plano de reserva usando esta abordagem como se deve fazer.nível do modelo (Carris) – o que estamos a falar agora!nível do controlador (Carris) tentador de usar, mas mais difícil de testar e manter. É uma convenção / melhor prática para manter seus controladores o mais leve possível.

quando é que realmente ocorre a validação?Straight from the ruby on rails documentation:

Existem dois tipos de objetos de registro ativos: aqueles que correspondem a uma linha dentro de sua base de dados e aqueles que não. Quando você cria um objeto novo, por exemplo usando o método new, esse objeto ainda não pertence à base de dados. Uma vez que você chama save sobre esse objeto, ele será salvo na tabela de banco de dados apropriada. Active Record uses the new_record? instance method to determine whether an object is already in the database or not.

criar uma nova classe de Registo activo dá-nos a oportunidade de usar um método new_record? para descobrir tudo isto.

class Article < ApplicationRecordend

ao fazê-lo, podemos atingirrails console para identificar o processo.

$ 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

na Verdade, chamar save é o que compromete-se ao banco de dados e os bastidores cria o necessário SQL instruções para fazê-lo. Como resultado, validações são normalmente executadas antes de enviar dados para o banco de dados inteiramente.

Os seguintes métodos de evocar, validações mediante a utilização:

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

A explosão de versões (ex: save!) gerar uma exceção caso o registo é inválido. As versões não-bang não: save e update voltar false e create retorna apenas o objeto.

métodos que ignoram validações

usando qualquer um dos seguintes irá ignorar validações inteiramente. Use com cuidado em dados valiosos!

• 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. Os ajudantes de validação são uma daquelas coisas que me fazem sentir quente e aconchegante ao lançar uma nova aplicação na natureza. Isso fornece um monte de suporte para uma grande variedade de dados que você pode estar coletando do lado do cliente.

cada auxiliar aceita uma opção :on e :message. Estas opções definem quando a validação deve ser executada e que mensagem deve ser adicionada a uma colecçãoerrors se falhar (pode usá-las para ajudar a injectar o que está errado dentro das suas vistas, para que o utilizador saiba o que alterar/alterar).

Há uma tonelada de ajudantes de validação, abaixo estão alguns dos meus mais usados. Por favor, confira o guia sobre validações de registros ativos para mais casos de uso.

confirmação

útil para validar quando dois campos de texto precisam ter o mesmo item. Pense em uma confirmação de E-mail, por exemplo.

class User < ApplicationRecord validates :email, confirmation: trueend

Agora, na sua opinião, você pode ter dois campos:

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

Uma pegadinha aqui é que essa validação só executa se o presence opção é definida como true no modelo de bem.

Então User modelo recebe um update:

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

a Exclusão

Se você precisa reservar qualquer palavra ou certifique-se de que uma dada entrada é sem igual, use exclusion.

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

Notice how I used:message here as well. Isto é fornecido em todos os ajudantes de validação.

Você também pode usar inclusion da maneira oposta. Veja os documentos para mais informações!

formato

formatação as cadeias de formatação são por vezes ideais para a sua aplicação. Você pode usar expressões regulares dentro de validações para alterar o que quer que você esteja atrás.

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

comprimento

i usar este o tempo todo para colocar uma restrição no comprimento do carácter de um dado campo.

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

Sinta-se livre para personalizar as mensagens com :message aqui também. A seguir, estão todos disponíveis para ligar para personalizar a mensagem.

• wrong_length
• too_long
• too_short

Exemplo

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

a Presença

Este é provavelmente o mais amplamente utilizado auxiliar no meu saco de ferramenta. A presença verifica se os campos não estão vazios.

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

Você também pode testar existe uma associação em modelos

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

Sobre a oposição do modelo, você pode fazer o mesmo com um problema chamado de inverse_of

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

Singularidade

Talvez você queira únicos nomes de usuário em seu aplicativo? A singularidade ajuda nisso.

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

Este, na verdade, procura o User tabela de registros existentes para determinar uniqueness

Você pode ir mais longe e limitar o uniqueness para a scope.

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

validações condicionais

às vezes você só precisa validar dentro de determinadas condições. Você pode realizar condicionalismos usando uma abordagem como a seguinte.

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

necessidade de agrupar condições múltiplas? Você pode fazer isso

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

métodos personalizados

às vezes os ajudantes não são suficientes e você pode precisar de algo mais personalizado. Você pode criar seus próprios métodos que fazem algumas validações que você rola a si mesmo.

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

Note aqui que estou a validar este método usando a opção :on que lhe permite determinar onde inicializar a validação. Neste caso, escolhi :create.

Pode também ligar-se à colecção errors pois tenho de alterar as saídas do lado do cliente, se necessário. Não temos o :message em métodos personalizados neste caso. Leia mais sobre erros.

Palavras Finais

esperançosamente, validações abriram algumas ideias para você tornar o seu aplicativo mais restrito (de uma boa maneira). Usando Ruby on Rails e todas as suas facetas permite que dados seguros para entrar em qualquer banco de dados de sua escolha. De fichas CSRF para validações de nível de banco de dados, há infinitas maneiras de melhorar o seu aplicativo pode permanecer calmo sobre os dados que vêm em.

Shameless Plug!se você gostou deste post, eu tenho mais vídeos no YouTube e aqui no meu blog. Quer mais conteúdo como este na sua caixa de entrada? Assine a minha newsletter e obtenha-a automaticamente.

Check out my course

☝ Want to learn Ruby on Rails from the ground up? Vejam o meu próximo curso chamado Hello Rails.