-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
fix(utils): Mikro orm repository update many to many should detach all items by default #9917
Conversation
…l items by default
The latest updates on your projects. Learn more about Vercel for Git ↗︎
6 Skipped Deployments
|
🦋 Changeset detectedLatest commit: e1d1001 The changes in this PR will be included in the next version bump. This PR includes changesets to release 65 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Sounds good to me! Maybe, we can highlight this behaviour change in our changelog, incase someone was passing empty array during API calls and now they will see that this behaviour results in detach within the pivot table. |
/snapshot-this |
1 similar comment
/snapshot-this |
FIXES FRMW-2758
What
In the current state, when calling a module service update method and providing a partial array for a many to many collection,. mikor orm automatically handle detaching the items that are not present in the array. But in the case an empty array is provided, nothing happen when we would expect all items to be detached automatically. This PR aims at fixing this behaviour (which is expected by mikro orm).
Note
As per mikro orm documentation, when relying on auto detach from a collection (such as using remove or remove all), one query per removal will be created, which is not performant. The expectation would be that the end user manage his collection manually and be aware of what is happening by explicitly managing those cases. for example, providing explicit methods to detach X items from a collection instead of relying on updating deeply from top to bottom.
But in the end, we still provide this shortcut and the user can choose, for simple cases where not a lot of items are involve, to use or not this simili cascade behaviour.