Discard foreign keys

[shlomi-noach]

Storyline: #262

This PR supports dropping of foreign keys from a table. There's nothing special about what gh-ost does to make that happen: it just doesn't do anything to create those foreign keys on the ghost table.

• contributed code is using same conventions as original code
• code is formatted via gofmt (please avoid goimports)
• code is built via ./build.sh
• code is tested via ./test.sh

[ggunson]

Can the docs say something as well about what it does to foreign keys that reference the migrated table? Even if that is repeating itself, that would be a good place to repeat it.

Sent from my iPad

On Oct 7, 2016, at 9:26 AM, Shlomi Noach notifications@github.com wrote:

Storyline: #262

This PR supports dropping of foreign keys from a table. There's nothing special about what gh-ost does to make that happen: it just doesn't do anything to create those foreign keys on the ghost table.

contributed code is using same conventions as original code
code is formatted via gofmt (please avoid goimports)
code is built via ./build.sh
code is tested via ./test.sh
You can view, comment on, or merge this pull request online at:

#264

Commit Summary

support for --discard-foreign-keys
documenting --discard-foreign-keys flag
File Changes

M build.sh (2)
M doc/command-line-flags.md (6)
M go/base/context.go (1)
M go/cmd/gh-ost/main.go (1)
M go/logic/inspect.go (12)
Patch Links:

https://github.com/github/gh-ost/pull/264.patch
https://github.com/github/gh-ost/pull/264.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[shlomi-noach]

@ggunson thanks for your comment, and I realize we need to refine this and only allow on tables with child-side FK. I don't wish to support any kind of parent-size FK handling at this time; it seems too dangerous to me (_del table dropped with on delete cascade --> whoops, all rows deleted from child table)

[shlomi-noach]

@ggunson a4d566e takes care of parent-side: not supported. Only child-side foreign keys can be discarded.

For people who are looking to compleltely eliminate foreign keys on their database, you should begin with child-most tables and move upwards.

I don't have an immediate solution to a self-referencing FK table.

[ggunson]

thanks for your comment, and I realize we need to refine this and only allow on tables with child-side FK.

@shlomi-noach I asked if the docs for this could say something about foreign keys referencing the table. So it was a suggestion that you add that to the docs you edited for this PR (e.g., the new flag description), that this doesn't apply to tables who are referenced in FKs from other tables.

[shlomi-noach]

@ggunson I was sure I did 😮 but then I realize I wrote this on another couple places. Will add.

Anyway, my original comment acknowledged that regardless of the docs, the code was wrong, and that is fixed. Proper error messages will indicate the limitation where someone tried to drop a parent-side foreign key. Docs were supposed to follow suit...