[11.x] Use getQualifiedOwnerKeyName in relations #53573
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is another attempt at my change in #53559, to use the existing
getQualifiedOwnerKeyName()
method rather than assuming the format oftable.column
. As @crynobone noticed, that change revealed that the current code can end up passing a null value tostr_contains()
, which is deprecated.I've added a null check to
getQualifiedOwnerKeyName()
so we don't attempt to qualify a null column. In the example of one of the tests that was throwing the deprecation notice (DatabaseEloquentIntegrationTest::testEmptyMorphToRelationship
) this means that in practice thewhere
query being added changes from$this->query->where('photos.', ...)
to$this->query->where('', ...)
. The 'add constraints' methods could be updated to handle null values differently, but I'm hoping the change I have here should be the minimum required to fix the issue properly with the lowest risk to other areas.