Schema migration: rename tables

[Maximiliano Robaina]

The alter_db_table method is used to rename table. In my case, Firebird doesn't allow rename tables because that implies alter related objects (store procedures, triggers, etc).
Maybe a database feature will needed to point this case.

So test_db_table method fails for me.

[Ben Davis]

The code for SQL operations is specific to the backend engine. I'm guessing the right place to file this is with the django-firebird project.

[Aymeric Augustin]

This is the maintainer of the django-firebird project asking ;-)

[Shai Berger]

Sometimes backends do things that the engine proper doesn't support by performing extra work -- the Sqlite backend, as a prime example, recreates tables as an implementation of alter-column; the usually-saner Oracle backend jumps through hoops to change a column from TextField to CharField or vice-versa, which isn't supported by the Oracle database.

Introducing the flag as requested here means that table-renaming is an optional feature of schema editors. That may be acceptable, or not -- I'm not even sure what I think of it. I think it may be worth a discussion on the DevelopersMailingList.

[Aymeric Augustin]

We've started down the path of adding flags for features not supported by third-party databases, so let's do this.

[Andrew Godwin]

Unfortunately, I think the correct thing for the backend to do here is the same as the SQLite backend - emulate the rename by making a new table and copying data across. SQLite also doesn't allow renames, but people expect certain stuff, so we had to emulate it.

Closing this as WONTFIX for now. If doing that proves unbelievably difficult, we could reopen and consider not supporting it as a feature flag, but that would mean that Firebird can't run some migrations (table rename is assumed to be possible by the autodetector, and as migrations are baked and shipped we can't have the autodetector change behaviour based on target database, as it doesn't know what the target is)