Say I have a fully built out resource (e.g. Activities which is powered by the public_activity gem - or any gem that you are using) that has the typical model, controller, views, etc. and you want to remove the entire gem and all existence of it through all instances of your app (development, test, production, etc.). What’s the best approach to doing this?
Doing rails d resource activities doesn’t work, because it just deletes the files (including the migration). Running the down action on that migration doesn’t work, because you then have to make sure that every developer does that in every instance of the app.
What I have found to be the most sustainable solution is to create another migration, e.g. RemovePublicActivity where you reverse the original migration (i.e. the up is now the down of the original, and vice versa), then just go through the app and delete things manually (delete the activity.rb model, the controller, the views, the specs, etc.).
But that seems very un-Rail-ish. At least when I do that though, and commit it, the next developer will be able to just pull, merge and run rake db:migrate and the app will be current.
How do you guys all tackle removing a deeply integrated resource?
Very interesting @benorenstein. I wonder if there has been discussion about this for the Rails core team. With all the wizardry that Rails provides, y was removing a resource neglected?
Sure, you can remove user.rb when I delete the User resource, but if that class used 5 other classes that are now unused, did the automatic deletion really help much?
LOL @Cyle_Hunter. Not sure about “one of the greatest joys”. Especially when the gem is deeply integrated in the app. Can easily become a nightmare…unless I am doing it wrong.
@marcamillion Ah, yeah… it’s usually only fun when it’s your own code you get to delete (i.e., refactoring). Been there done that, looking at you can_can! shudders
