-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the wrong foreign key on columns.column_name #466
Comments
For me https://github.com/airbnb/caravel/pull/531/files fixed the issue |
Yes, because it is specialized for MySQL and will only work on MySQL. You can try it on SQLite or other databases. It won't work because the foreign key is not named that way |
That's why I said I want a "universal migration script that works on every SQL dialects" |
Yes,it can't get the real value from the foreign key on SQLite |
Models show correct foreign key now. Closing the issue. |
Are you sure? It's not about the model, I know the model was fixed. The problem is whether the underlying database is migrated correctly. |
@x4base - you right, looks like migrated DB doesn't have the foreign keys: |
In the commit c2bb49f, the foreign key that references datasource.datasource_name was set on columns.column_name when it should be columns.datasource_name. This causes errors when there are any new columns to be created when refreshing the druid datasources.
I am trying to generate a migration script to fix this. However, op.drop_constraint() requires the name of the foreign key you want to drop.
The following code works on SQLite because the foreign keys don't have any names:
But for MySQL, the foreign keys are named like "columns_ibfk_1". Should I presume that on every machines, this foreign key has the same name and just drop the foreign key named columns_ibfk_1?
Do you have any suggestion about how to write a universal migration script that works on every SQL dialects? Or should I iterate through the known default names in different dialects in try-catch blocks?
I just couldn't figure out a way to drop the foreign key without knowing its name.
The text was updated successfully, but these errors were encountered: