fix: should not use flush_after() in FactoryCollection::create() #908
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
nikophil
force-pushed
the
tests/find-or-create-in-create-many
branch
from
7ce0936 to
395ca01
Compare
nikophil
commented
May 25, 2025
| #[Test] | ||
| #[DataProvider('provideCascadeRelationshipsCombinations')] | ||
| #[UsingRelationships(Contact::class, ['category'])] | ||
| public function ensure_inverse_one_to_many_is_hydrated_before_persisting_in_flush_after(): void |
There was a problem hiding this comment.
I'm not 100% sure the name of the test is accurate, this edge case is pretty specific 🙈 (it reproduces #911)
nikophil
commented
May 25, 2025
| #[Test] | ||
| #[DataProvider('provideCascadeRelationshipsCombinations')] | ||
| #[UsingRelationships(Contact::class, ['category'])] | ||
| public function find_or_create_used_in_many_actually_create_only_one_object(): void |
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
|
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 |
nikophil
force-pushed
the
tests/find-or-create-in-create-many
branch
2 times, most recently
from
fb5516a to
28d44f6
Compare
nikophil
force-pushed
the
tests/find-or-create-in-create-many
branch
from
28d44f6 to
7c8c308
Compare
|
🌹 |
|
@smnandre does this fixes the problem you told me about? |
|
Pretty sure, i'll test friday |
|
I will, trust me 😆 |
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