Temporarily recreate already dropped functions in the discourse_functions schema in order to allow restoring of backups which still reference dropped functions.
You’ve signed the CLA, gschlager. Thank you! This pull request is ready for review.
Does this mean in the future we must create the constants
DROPPED_COLUMNS in order for things to work properly?
Yes, exactly. I couldn’t think of another way of knowing which functions to create. Now that you mention it I could add a spec that ensures that post migrations contain the right constants when
TableDropper are used. That should prevent mistakes in most cases.
I went ahead and added specs to check the post migrations.
This is definitely better, but I wonder if there’s a way we could query directly as a result of the ColumnDropper calls? Could those calls set some class variables in a certain context and then allow us to check those variables?
That’s actually a good idea! The migrations aren’t running during the restore, but I guess I could load them as I do right now and execute the
change method. Running them in a block that makes the
execute_drop calls only record the table and column names should be possible. I can give it another go.
Actually, that won’t work. There’s other code in some of those migrations and I can’t blindly execute all post migrations.
Ah too bad. Was worth a look though!