Consistency between database constraints and ActiveRecord validations (database_consistency gem)

[DjezzzL]

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 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 to spread the info about the gem. 

[Greg Navis]

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

[DjezzzL]

Hi, thank you!

I'm wondering whether our tools different in how they treat different cases.

Oh, I wish I find it earlier :) 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

[Greg Navis]

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

[DjezzzL]

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

--
You received this message because you are subscribed to a topic in the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubyonrails-talk/2TaG_XAsF9k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAA6WWt96O0NZaeLBhs3n3YgZQnYZh-hW5gHRrnh-RFGGz2QgAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.