Allow flush management command to drop tables and re-run migrations

[Pradeek]

This means that after running flush, migrate does not have any effect. This makes it difficult when the migrate command is responsible for loading fixtures, which according to the docs seems to be the way forward.

Looking for feedback on how we want to do this. Should we clear the migrations table on flush or should there be a flag that has to be manually added?

[Tim Graham]

Clearing the migrations history would mean that all schema migrations would need to be faked. I think it would be easier to drop the database and re-run the migrations. Attached is a proposed documentation patch to suggest that. What do you think?

[Pradeek]

The reason why I proposed this, is because Django previously loaded initial data during flush. Such a functionality cannot be replicated here without going outside the management commands and dropping the db manually. I personally think flush without loading fixtures (assuming migrations will be the only way to do initial data in the future) would not be of much use / and feels broken. I think we should be able to fake schema migrations but still run python migrations on flush.

[Tim Graham]

The problem what that approach is that older data migrations may not run on the current version of the schema.

An option to "flush" by deleting all managed tables and re-running migrations from the beginning might be acceptable. In the meantime, does the documentation patch look okay?

[Pradeek]

Yeah. The documentation patch is fine.

Reg adding an option to flush, what other managed tables should be cleared? Will take a crack at adding it.

[Tim Graham]

It would operate on the same tables, but "DROP" them instead of "TRUNCATE". By managed I meant, ​Options.managed.

[Tim Graham <timograham@…>]

In 4870b30:

Removed initial data from flush docs since it's removed; refs #24711.