FIX: Create readonly functions during backup

[gschlager]

Temporarily recreate already dropped functions in the discourse_functions schema in order to allow restoring of backups which still reference dropped functions.

[discoursebot]

You've signed the CLA, gschlager. Thank you! This pull request is ready for review.

[eviltrout]

Does this mean in the future we must create the constants DROPPED_TABLES, DROPPED_COLUMNS in order for things to work properly?

[gschlager]

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 ColumnDropper or TableDropper are used. That should prevent mistakes in most cases.

[gschlager]

I went ahead and added specs to check the post migrations.

[eviltrout]

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?

[gschlager]

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 up or 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.

[gschlager]

Actually, that won't work. There's other code in some of those migrations and I can't blindly execute all post migrations. :/

[eviltrout]

Ah too bad. Was worth a look though!