Opened 2 years ago

Closed 2 years ago

#22784 closed Cleanup/optimization (wontfix)

Schema migration: rename tables

Reported by: Maximiliano Robaina Owned by: nobody
Component: Migrations Version: 1.7-beta-2
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (5)

comment:1 Changed 2 years ago by Ben Davis

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

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.

comment:2 Changed 2 years ago by Aymeric Augustin

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

comment:3 Changed 2 years ago by 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.

comment:4 Changed 2 years ago by Aymeric Augustin

Triage Stage: UnreviewedAccepted
Type: UncategorizedCleanup/optimization

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

comment:5 Changed 2 years ago by Andrew Godwin

Resolution: wontfix
Status: newclosed

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)

Note: See TracTickets for help on using tickets.
Back to Top