Consistency between database constraints and ActiveRecord validations (database_consistency gem)

After a while of development your project, you might notice that you have some inconsistencies between your database constraints and validations. Right now, we will talk about two possible situations.

Case #1.

Imagine you defined your table as following:

create_table :users do |t|
t.string :name
end


And your model definition:

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

 
In this case, the validation can be skipped by some methods and the null value will be inserted in the database. In most cases, you probably don't want this to happen so it's better to have not null constraint in the database.

**Case #2**.

Imagine you defined your table as following:

create_table :users do |t|
  t.string :name, null: false
end

And your model definition:

class User < ApplicationRecord
end

In this case, the **valid?**`` method will return **`true`** for the records which cannot be created. Moreover, the attempt to insert a row will execute from 1 up to a few SQL queries and in a result raise an error and rollback the whole transaction. Those all things are **very inefficient** and can be easily skipped by just adding presence validation. You should add it in most cases.

So the question is how to find all possible issues automatically without manually checking all models?

Here [database_consistency](https://github.com/djezzzl/database_consistency) gem comes in handy. Right now, it detects most of issues. Also, it helps us to detect the issue where a column has not-null constraint but there is possible `null` insert defined by the optional presence validator.

*Try it yourself and share your feedback. Feel free to contribute! Any thoughts are welcome!
P.S. This is my own topic was copy-pasted from [reddit](https://www.reddit.com/r/rails/comments/9x1lsd/consistency_between_database_constraints_and/) to spread the info about the gem. *

Nice work! I implemented a similar feature in active_record_doctor and I’m wondering whether our tools different in how they treat different cases.

What other features are planning on implementing?

Best regards

Greg Navis

Hi, thank you!

I’m wondering whether our tools different in how they treat different cases.
Oh, I wish I find it earlier :slight_smile: I could check your implementation. My way is described in the README.

What other features are planning on implementing?
I don’t know yet. But I see you have few already. That’s good. Probably I should better make a PR to your repo instead mine to keep things together but I need an idea for that. Maybe you have?

Kind regards,

Evgeniy Demin

I’m thinking about 2.0 and want to make it useful in a CI setting. For example, currently there’s no way to ignore a warning so it’d always break the build even if it’s by design.

Best regards

Greg Navis

Actually, I was thinking about exactly the same, I have already configurable YAML file to skip some part of the system’s check. So now, it will be good, to skip some particular issues if we want them to persist.

I’m also was thinking about a few features you already have, so I don’t know what to do. Is it fine if I implement them too but with my own code? WDYT?

Kind regards