Frequent false positives on "isolate seed data"

[hakanai]

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?

[jelhouss]

Personally I run into a situation where I had to disable this rule on migrations files, because I was creating data inside of migrations hooks (up or down) and this rule gave a false positive lint issue. Write IsolateSeedDataCheck: { ignored_files: ["db/migrate"] } in rails_best_practices.yml config file. I think it's a good way to disable it in migrations.