Skip to content
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

[5.5] Allow setting custom morphTo ownerKey #21235

Closed
wants to merge 2 commits into from
Closed

[5.5] Allow setting custom morphTo ownerKey #21235

wants to merge 2 commits into from

Conversation

v0ctor
Copy link
Contributor

@v0ctor v0ctor commented Sep 18, 2017

As proposed at laravel/ideas#587, this PR adds the ability to set a custom ownerKey when defining a morphTo polymorphic relationship.

Method definition is equivalent to morphOne and morphMany, among others, so it brings consistency to relationship definitions while providing the freedom to use them with data models that can not be easily modified. It is fully backwards compatible with Laravel 5.5 LTS.

Please tell me what you think about this PR. If you know any way to do it better or you think that it is unsuitable, feel free to give your opinion. Thanks!

@taylorotwell
Copy link
Member

It's not fully backwards compatible because it changes function signatures.

@v0ctor
Copy link
Contributor Author

v0ctor commented Sep 18, 2017

@taylorotwell I think I do not understand the problem. The new parameter has a default value, so the new function signature of morphTo is compatible with the old one. How does this affect backward compatibility?

Anyway, what would be the correct way to implement it? Or should I have done the pull request on the master branch?

@v0ctor
Copy link
Contributor Author

v0ctor commented Sep 21, 2017

I have resubmitted this PR to master (#21310). I hope it's the right way.

@paulofreitas
Copy link
Contributor

@victordzmr Every function signature change is a potential breaking change. When changing a class/trait that is intended to be extended by the user it's always a BC break because people often overload those methods to change the framework behavior. Contracts on other hand should never be changed as their changes would always break things.

Some BC breaks may impact the user base badly and others may went unnoticed. In those situations submitting the change to a future release is always the safest choice. 😉

@v0ctor
Copy link
Contributor Author

v0ctor commented Sep 22, 2017

@paulofreitas I had not thought of that possibility. Thank you very much for the explanation! 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants