-
Notifications
You must be signed in to change notification settings - Fork 190
Add support for tables with outbound foreign key constraints. #36
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
Conversation
|
Thanks a lot for looking into this! I'm packed with stuff today, will have a look at this tomorrow or Thursday. |
|
I just realized that the mechanism to generate the constraint names is even less ideal than I thought. It will probably fail if you try to run LHM on a table twice. I’m going to take a stab at improving it this morning, but I have a lot going on. |
|
The newest commit is a bit more invasive than I’d like, but it solves the problem much more robustly. And sets things up to work on fixing inbound foreign keys as well. |
Brute force the new constraint names by offsetting the (optional) index in the name by the total number of keys.
Reads all of the constraint names and makes sure to choose one that does not clash.
…than just dropped.
…e constraints are already stored in indices
Do not assume it is present.
|
I just rebased everything off the most recent upstream master and fixed the last of the failing builds. I think this one is good to go. |
|
tested and works great. +1 for merge. Now we just need self-referential constraints and inbound constraint support. |
|
I tested this, but it didn't work on tables having more than one foreign key. |
|
I don't believe I ran in to that problem, even with multiple FKs |
|
Thanks for the PR, #77 is a more complete solution, so I will try to get that one merged in. thanks again. |
This branch allows LHM to migrate tables with (outbound) foreign key constraints by renaming the constraints on the destination table.