DatabaseValidations helps you to keep the database consistency with better performance. Right now, it supports only ActiveRecord.
The more you use the gem, the more performance increase you have. Try it now!
Add this line to your application's Gemfile:
gem 'database_validations'And then execute:
bundleOr install it yourself as:
gem install database_validationsHave a look at example application for details.
Benchmark (code)
Imagine, you have User model defines as
class User < ActiveRecord::Base
validates :email, :full_name, uniqueness: true
belongs_to :company
belongs_to :country
endand then replace with
class User < ActiveRecord::Base
validates :email, :full_name, db_uniqueness: true
# OR
# validates_db_uniqueness_of :email, :full_name
db_belongs_to :company
db_belongs_to :country
# OR
# belongs_to :company
# belongs_to :country
# validates :company, :country, db_presence: true
endyou will get the following performance improvement:
db_belongs_todoesn't work with SQLite due to a poor error message.- In Rails 4, the gem validations work differently than the ActiveRecord ones when
validate: falseoption is passed tosave/save!. They incorrectly return a validation message instead of raising a proper constraint violation exception. In Rails >= 5 they correctly raise the exceptions they supposed to.
Supported databases are PostgreSQL and MySQL.
Note: Unfortunately, SQLite raises a poor error message
by which we can not determine exact foreign key which raised an error.
class User < ActiveRecord::Base
db_belongs_to :company
end
user = User.create(company_id: nil)
# => false
user.errors.messages
# => {:company=>["must exist"]}ActiveRecord's belongs_to has optional: false by default. Unfortunately, this
approach does not ensure existence of the related object. For example, we can skip
validations or remove the related object after we save the object. After that, our
database becomes inconsistent because we assume the object has his relation but it
does not.
db_belongs_to solves the problem using foreign key constraints in the database
also providing backward compatibility with nice validations errors.
Advantages:
- Ensures relation existence because it uses foreign keys constraints.
- Checks the existence of proper foreign key constraint at the boot time.
Use
ENV['SKIP_DB_UNIQUENESS_VALIDATOR_INDEX_CHECK'] = 'true'if you want to skip it in some cases. (For example, when you run migrations.) Note: we skip it for the abstract classes. - It's almost two times faster because it skips unnecessary SQL query. See benchmarks below for details.
Disadvantages:
- Cannot handle multiple database validations at once because database raises only one error per query.
| Option name | PostgreSQL | MySQL |
|---|---|---|
| class_name | + | + |
| foreign_key | + | + |
| foreign_type | - | - |
| primary_key | + | + |
| dependent | + | + |
| counter_cache | + | + |
| polymorphic | - | - |
| validate | + | + |
| autosave | + | + |
| touch | + | + |
| inverse_of | + | + |
| optional | - | - |
| required | - | - |
| default | + | + |
Benchmarks (code)
Supported databases are PostgreSQL, MySQL and SQLite.
class User < ActiveRecord::Base
validates :email, db_uniqueness: true
# The same as following:
# validates :email, uniqueness: {case_sensitive: true, allow_nil: true, allow_blank: false}
end
original = User.create(email: '[email protected]')
dupe = User.create(email: '[email protected]')
# => false
dupe.errors.messages
# => {:email=>["has already been taken"]}
User.create!(email: '[email protected]')
# => ActiveRecord::RecordInvalid Validation failed: email has already been takenComplete case_sensitive replacement example (for PostgreSQL only):
validates :slug, uniqueness: { case_sensitive: false, scope: :field }Should be replaced by:
validates :slug, db_uniqueness: {index_name: :unique_index, case_sensitive: false, scope: :field}Keep in mind: because valid? method uses default validator you should:
- if your index has many fields, provide proper
scopeoption - if your index has lower function, provide
case_sensitiveoption - if your index has where condition, provide proper
whereoption
Unfortunately, ActiveRecord's validates_uniqueness_of approach does not ensure
uniqueness. For example, we can skip validations or create two records in parallel
queries. After that, our database becomes inconsistent because we assume some uniqueness
over the table but it has duplicates.
validates_db_uniqueness_of solves the problem using unique index constraints
in the database also providing backward compatibility with nice validations errors.
- Ensures uniqueness because it uses unique constraints.
- Checks the existence of proper unique index at the boot time.
Use
ENV['SKIP_DB_UNIQUENESS_VALIDATOR_INDEX_CHECK'] = 'true'if you want to skip it in some cases. (For example, when you run migrations.) Note: we skip it for the abstract classes. - It's two times faster in average because it skips unnecessary SQL query. See benchmarks below for details.
- It has different modes so you can pick up the best for your needs.
| Option name | PostgreSQL | MySQL | SQLite |
|---|---|---|---|
| mode | + | + | + |
| scope | + | + | + |
| message | + | + | + |
| if | + | + | + |
| unless | + | + | + |
| index_name | + | + | - |
| where | + | - | - |
| case_sensitive | + | - | - |
| allow_nil | - | - | - |
| allow_blank | - | - | - |
The validation has an option :rescue with two values:
:default(default option) that follows default ActiveRecord behavior. It respectsvalidate: falseoption forsave/save!(for example, this is being used for nested associations):alwaysthat catches database constraint errors and turns them to ActiveRecord validations filling.errorsproperly.
You may want to use rescue: :always in case you save nested associations with accepts_nested_attributes_for helper and you want the validation to happen automatically when a user
provides duplicated data in the same request.
There are 3 mode options:
:optimized- the default one. In this mode it turns DB constraint exceptions into proper validation messages.:enhanced- a combination of the standard uniqueness validation and the db uniqueness validation. Runs a query first but also rescues from exception. The preferable mode for user-facing validations.:standard- in this mode works pretty much the same way asvalidates_uniqueness_of(except the index existence check).
Benchmark (code)
Add require database_validations/rspec/matchers' to your spec file.
Example:
class User < ActiveRecord::Base
validates_db_uniqueness_of :field, message: 'duplicate', where: '(some_field IS NULL)', scope: :another_field, index_name: :unique_index
end
describe 'validations' do
subject { User }
it { is_expected.to validate_db_uniqueness_of(:field).with_message('duplicate').with_where('(some_field IS NULL)').scoped_to(:another_field).with_index(:unique_index) }
endDatabaseValidations provides custom cops for RuboCop to help you consistently apply the improvements.
To use all of them, use rubocop --require database_validations/rubocop/cops or add to your .rubocop.yml file:
require:
- database_validations/rubocop/copsOr you case use some specific cop directly:
require:
- database_validations/rubocop/cop/belongs_to
- database_validations/rubocop/cop/uniqueness_ofYou need to have installed and running postgresql and mysql.
And for each adapter manually create a database called database_validations_test accessible by your local user.
Then, run rake spec to run the tests.
To check the conformance with the style guides, run:
rubocopTo run benchmarks, run:
ruby -I lib benchmarks/composed_benchmarks.rbTo install this gem onto your local machine, run bundle exec rake install.
To release a new version, update the version number in version.rb, and then
run bundle exec rake release, which will create a git tag for the version,
push git commits and tags, and push the .gem file to rubygems.org.
Bug reports and pull requests are welcome on GitHub. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.
The gem is available as open source under the terms of the MIT License.
Everyone interacting in the DatabaseValidations project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.


