Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Limitations of declarative approach #5
Illustrated below are two use cases the declarative approach cannot handle, and in fact requires an added insight from the user, namely the very
RENAME (CHANGE) COLUMN
Consider this tests from gh-ost:
create table gh_ost_test ( id int auto_increment, c1 int not null, c2 int not null, primary key (id) ) auto_increment=1; insert into gh_ost_test ...
alter table gh_ost_test change column c2 c3 int not null
create table gh_ost_test ( id int auto_increment, c1 int not null, c3 int not null, primary key (id) ) auto_increment=1;
2. DROP+ADD COLUMN
This is the opposite for the
Consider this gh-ost test:
create table gh_ost_test ( id int auto_increment, c1 int null, c2 int not null, primary key (id) ) auto_increment=1;
alter table gh_ost_test drop column c1, add column c1 int not null default 47
create table gh_ost_test ( id int auto_increment, c1 int null, c2 int not null default 47, primary key (id) ) auto_increment=1;
I would suggest at first add these two in Unsupported for ALTERs so that the issue is known.
Otherwise I would recommend a potential add-on of the original
Good point -- lack of rename support is mentioned in passing in a couple docs (examples.md and faq.md) but really should be mentioned explicitly in the Unsupported section. I'll update that momentarily.
In terms of how Skeema currently handles these two cases:
The first case would indeed result in an ALTER doing a DROP COLUMN followed by an ADD COLUMN. But Skeema automatically flags all destructive operations as "unsafe", and will flag them as an error (skipping them and any other alters on same table) unless
Similar situation with renaming tables btw.
The second situation would indeed generate an ALTER changing the default. I'd argue this situation is contrived -- I haven't ever encountered a real situation where a user wanted to remove a column, and then replace it with another column of same name, but without wanting the old data to be present. If a user wants to remove the data from a column, they should use DML for this purpose, not DDL.
Anyway, re: the first situation / renames, current work-around is to do the rename operations on database(s) manually (outside of Skeema), and then use
In terms of future support for renames: Although http://github.com/skeema/tengo could easily be used to detect the situation where only a name of a col or table changed (simply by comparing the other fields of the relevant Go structs), I'd rather require users to be explicit about wanting renames. I have some thoughts on how this could work, involving table and column comments. Interestingly, Luke from FB independently had the same thought in how to eventually support renames in fb-osc.py (which doesn't support renames yet either, as FB historically has disallowed renames in prod.)
DBAs at several other companies have indicated similar no-renames-in-prod policies, so I'm hesitant to prioritize this too highly. As you're undoubtedly aware, renames present a deploy-order problem at scale: it's impossible to deploy application code at the exact same time as a prod column or table rename in the database takes effect.
Slightly higher priority is the notion of rename-before-dropping: an option to replace drops with renames automatically. For example, if you want to drop column
Neither have I, until github/gh-ost#384. I agree it's a rare case.
I also agree on the