You cannot delete old Rails Engine migrations which is inconsistent with what the docs say

According to the Active Record Migrations Old Migrations section you can delete old migration files. There are many articles which recommend doing this, for a variety of reasons such as cleaning up the code base.

However, Rails Engines work by copying over migrations and adding a special comment to them (

This means that if I delete all old migrations and then re-run rails blorgh:install:migrations, it will add the engine migrations again, and re run them, which will cause migration errors.

I think this is either a bit of an inconsistency with the docs (specifically where it says you can delete old migrations), or an issue with how the engine migrations work.

I think when you install Rails Engine migrations a special file should be created indicating which engine migrations have been installed, that way if you try to install migrations again, it won’t have to rely on the migrations existing in the db/migrations/ directory.

Does this sound like a good idea? Am I missing something with Engines which would let you delete old migrations on the main app without any issues?

1 Like

And how should the existing engines behave in this scenario? I mean, an already installed engine will not have this file, so when installing the engine again it won’t be able to check if the migrations need to be generated again or not.

I think that a good idea would be document this behavior in the docs

1 Like

Why rerun? If they were run in the past, that’s registered in schema_migrations (that you do not need to trim), and the newly installed files are ignored.

If they are regenerated by rails blorgh:install:migrations would they not have new timestamps making them new entries as far as the schema_migrations table is concerned?

Ahhh, I see the install task generates new timestamps for missing migrations, and detects already installed ones despite the timestamp. Yes, you’re right.

By now, addressed in the docs themselves: