Add support for multiple outbound foreign keys constraints

[pomier]

This adds support for tables with multiples outbound foreign keys constraints. This is a modification of pull request #36 who allowed only one foreign key constraint.

The original problem in issue #34 was that lhm tries to create a table with foreign keys constraint having the same name than the original table, producing an error. #36 tried to fix it by modifying the last number at the end of the name. table_ibfk_1 would then become table_ibfk_2.
The problem was that the new constraints names were the same when the table had more than one outbound foreign keys, producing the same error than before. Another problem with that solution is that the names produced are not consistent when you undo or redo a migration. The original names are lost forever, so undo a migration won't give you the same structure than before. The new name depends on the original name, so redo a migration may not give the same structure either.

My solution appends a suffix "_lhmn" to the constraint name. If the suffix is already there, we remove it in the new name. If you apply two change_table, the constraint names will then be exactly as before. This allows migrations undo and redo to work as they should. Besides, the uniqueness of constraints names is no longer a problem, making lhm support as many outbound foreign key constraints as necessary.

[pomier]

Thanks to #82, the build has passed and this pull request is ready to be merged 😉

[masylum]

What is needed to get this PR merged? Can we help on getting it merged?

[undergroundwebdesigns]

Bump, I'd also like to use this, is anything I can do to help get this merged?

[arthurnn]

Yes, this is a problem, and we need to fix it.
I like the solution you proposed, however I am having a bit trouble follow the code, Can you squash all commits in one and rebase this from latest master.
After that I can give a last look and merge it in.

thanks

[pomier]

I've squashed the commits and rebased the branch.

[quentindemetz]

@arthurnn how does it look? We've been using @pomier's fork in production at PriceMatch for a while now and haven't run into any issues.

Thanks!

[trobrock]

👍

[arthurnn]

Now that we only support ActiveRecord, would be cool to use the FK method they provide https://github.com/rails/rails/blob/4-2-stable/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb#L538-L548 , Only problem is that is only on rails 4.2+ . So maybe we should copy/paste that logic, if we are running on rails 4.2- . WDYT?

[quentindemetz]

I think we should focus on getting this out instead of continuously commenting / rebasing / refactoring once every six months. It's tested, and it's been working live for months now. It won't be too late to refactor it later to include the relevant rails 4.2 logic if that really stands out as a priority.

[quentindemetz]

@arthurnn @hannestyden I would be most thankful if you could merge this ? Thanks guys.

[ghempton]

👍 any remaining work here?

[flushentitypacket]

Just ran into this problem today. Thanks for putting in the work to resolve this!

[todd]

Any update on this? Would love to see this merged.

[treyx]

👍 Also running into this problem. Thanks for looking into the fix

[buffym]

Just got bit by this one too... 👍

[ghempton]

It's been almost a year since this PR was made. Can we get a maintainer to chime in on what it would take to get this merged in (if at all)?

[pomier]

I've rebased this PR from latest master.

The tests are now randomly failing the same way it currently happens on master branch. Apart from that, everything is ready to be merged any time now.

[trobrock]

@arthurnn not sure if you are the right guy, but maybe you can point to the right person. What needs to be done to get this merged? It's the only thing preventing me from using this, and right now i have to resort to downtime migrations 😞

[quentindemetz]

@trobrock you can always use @pomier's fork directly in your gemfile:

gem 'lhm', git: 'https://github.com/pomier/lhm', branch: 'outbound-foreign-keys'

It's been rebased on this repo recently which means there are little drawbacks to using this fork IMO.

[flushentitypacket]

Kind of frustrating that project maintainers aren't moving at all on this PR. This is incredible work and would really improve the gem.

[myers]

I wish this PR was merged. It would solve the problem I have this morning.

[soulfly]

Guys, any updates with this merge?

[twelvelabs]

@arthurnn are there still changes required before this can be merged, or are you looking for a totally different direction? We'd like to avoid using a fork if at all possible.

[shiju-d]

Hey Guys, Can we get this merged and avoid fork?

[tooluser]

@arthurnn We would love to get this in - and are willing to help with this if any changes are needed and help is desired. Can any maintainer let us know whether this is a good direction for the solution, and/or what we can do to help?

[sweetleon]

Any chance of getting this merged? It'd really help my project.

[tboyko]

door stuck

[dinesh-rdk]

It's 2020!!!

[SenikTony]

It's 2021!!! Knock-Knock...

[tboyko]

FWIW, the Shopify fork is more active these days.