fix: should not use flush_after() in FactoryCollection::create()#908
Merged
nikophil merged 1 commit intoMay 30, 2025
Merged
Conversation
7ce0936 to
395ca01
Compare
nikophil
commented
May 25, 2025
nikophil
commented
May 25, 2025
There was a problem hiding this comment.
Pull Request Overview
Reproduces and fixes issues #907 and #911 by adjusting flush behavior when using findOrCreate() inside createMany(), replacing flush_after() in core logic and adding robust tests.
- Added integration tests covering
findOrCreate()in bulk creation and ensuring inverse relationships are hydrated before flush. - Changed the persistence layer’s
save()to accept multiple objects and flush in one operation. - Refactored
FactoryCollection::create()to use the new multi-objectsave()instead of theflush_after()helper.
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| tests/Integration/ORM/EntityRelationship/EntityFactoryRelationshipTestCase.php | New test cases for bulk findOrCreate() and flush_after() behavior |
| src/Persistence/functions.php | Updated save() helper to delegate to the new persistence API |
| src/Persistence/PersistenceManager.php | Expanded save() to accept variadic objects and flush appropriately |
| src/FactoryCollection.php | Removed flush_after() usage in create() in favor of direct saves |
Comments suppressed due to low confidence (1)
src/Persistence/functions.php:122
- Consider adding or updating the docblock above this helper to explain that it now always returns the original object (the underlying persistence manager no longer returns the entity).
function save(object $object): object
Member
Author
|
I don't know what's happening in this PR: seg fault in codecov, paratest which takes forever... 🤷 EDIT : OK I know why, that's because of data providers |
28d44f6 to
7c8c308
Compare
Contributor
|
🌹 |
Member
Author
|
@smnandre does this fixes the problem you told me about? |
Contributor
|
Pretty sure, i'll test friday |
Contributor
|
I will, trust me 😆 |
d9e3c8a to
0db079b
Compare
0db079b to
90c1014
Compare
Member
Author
|
this was released in 2.5.3 🙂 |
Contributor
|
Not conclusive... we still have something weird with clear and collections, but it's more and more probable recent changes in Foundry simply exposed a bug that was already here in our code |
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
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.
this reproduces both #907 and #911 and fixes them (two issue, same fix) - @phasdev did add a feature flag for flush once, but the bug still remains.
flush_after()was definitely not a good idea inFactoryCollection::create(): "flush once" behavior should not be a hard requirement, and something likefindOrCreate()should actually flush.thanks again to @phasdev, the reproducers were very helpful!
fixes #907 fixes #911