Belongs to many eager bugfix #12
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
…tionary to mutate dictionary keys from pivot records when the pivot parents keys are mutated
Contributor Author
| @khepin Check this out when you can! (I can't add you as a reviewer for some reason). |
Contributor
| 👍 |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Eager loading for belongsToMany was not working for two reasons.
addEagerConstraintswas just adding parent keys directly and not unserializing (easy fix)addEagerConstraintswas updated to work, results were being fetched but they were not being matched to their parents. This was happening because the dictionary (used for matching) that is built, uses the pivot's foreign key value as a key for matching and because the pivot doesn't have defined mutators, it was using the serialized value as a key (in the test's example, using binary version of the value). Then when trying to match it would use the related records accessor which would unserialize and then not match. I figured it best to just mutate when the parentPivot has a mutator instead of making the Pivot record deal with mutators so it will always work (without custom pivots), and then if a user of the library does have a custom pivot they dont have to worry about extending our custom pivot, they can just extend laravel's pivot and be fine without worrying about mutators.