flyerhzm / rails_best_practices

a code metric tool for rails projects
http://rails-bestpractices.com
MIT License
4.16k stars 276 forks source link

Frequent false positives on "isolate seed data" #399

Open hakanai opened 1 year ago

hakanai commented 1 year ago

While I agree with "isolate seed data" as a best practice, most of the cases where we're tripping this warning aren't cases which could be sensibly moved to seed data.

For example, it also occurs on migrations half way through the lifecycle of our application - years after the production server was created - which are in migrations specifically because they do need to be run on production servers to bring the database to a consistent state.

If we moved such code to the seeds, they would not be run, so the production server wouldn't work anymore.

Example: Say you have some category type, where all items must have a category. When you create the server for the first time, there are no items, and thus no need for any categories. You want to leave category creation to the site admin, but in the migration where you introduce categories for the first time, you have to create some category to assign to all the existing items, otherwise the database is in an inconsistent state. Leaving it nil and dealing with the nil from the code is dirtier, so what we do is create a placeholder category and then assign that for all current items.

In the meantime, is there a way to suppress individual cases of this, or is skipping the entire file the only option?