- What does endroid/flusher do?
- endroid/flusher is a small Doctrine ORM utility that wraps EntityManager::flush() with a self-tuning batch-size heuristic. You create a Flusher with your entity manager, call flush() as you persist entities, and call finish() to flush any remaining data. It incrementally probes new batch sizes, keeps the fastest, and switches when conditions change.
- Does endroid/flusher work with Laravel's Eloquent ORM?
- No. Laravel's default persistence layer is Eloquent, and endroid/flusher is built around Doctrine ORM's EntityManager. It only fits Laravel applications that already use Doctrine ORM, typically through laravel-doctrine/orm. For an Eloquent codebase it is not a relevant dependency.
- How do I install endroid/flusher in a Laravel app?
- Install it with composer require endroid/flusher. There is no Laravel service provider, config file, or facade, so you wire it manually in a queued job or console command. Instantiate Flusher with your Doctrine EntityManager and pass a step size if you need to control probing.
- How do I use endroid/flusher when importing large data sets?
- Persist each entity through your Doctrine EntityManager and call the flusher's flush() method inside the loop. After the loop, call finish() so any pending batch is flushed. The README example persists 50,000 Task entities this way.
- Which Doctrine ORM and PHP versions does endroid/flusher support?
- The package does not publish a clear, current support matrix in the provided context, so check its composer.json constraints before adopting it. Pay particular attention to Doctrine ORM 3.x and PHP 8.2+ compatibility, because there is no evidence of recent CI runs against those versions. Test the exact combination in your application rather than assuming Laravel-style support guarantees.
- Is endroid/flusher safe for production bulk imports?
- Treat it as high risk on the write path. The project has weak maturity signals: around 7 GitHub stars, 0 dependents, a single maintainer, readme-only documentation, and an aggregate score of 0.065. A failure can surface as partial or corrupted imports, not a cosmetic bug, so benchmark and test it in a non-critical job first.
- Does endroid/flusher handle a closed or rolled-back EntityManager?
- The provided context does not document how endroid/flusher reacts to a closed or rolled-back EntityManager mid-import. Because the flusher performs tuning retries around flush calls, you should verify that the original exception is surfaced cleanly and not masked. Add an integration test that forces a rollback during an import before relying on it.
- Is the batch size tuning deterministic enough for performance tests?
- Not guaranteed. The heuristic probes batch sizes incrementally and adapts to observed performance, which is inherently sensitive to hardware, database driver, and load. For reproducible performance tests, compare against fixed batch sizes and record the tuning decisions. If you need deterministic runs, a benchmarked fixed batch size may be the better choice.
- How does endroid/flusher compare to using a fixed batch size?
- A fixed, benchmarked batch size is simpler and often sufficient, especially for low-volume or infrequent imports. endroid/flusher only makes sense when sustained bulk imports run across heterogeneous workers and flush batch size materially affects throughput or memory. Benchmark your pipeline first and promote the flusher only if it beats the best fixed size by a meaningful margin, such as more than 15 percent.
- Is endroid/flusher actively maintained, and should I fork it?
- Maintenance risk is the main concern: one maintainer, no dependents, and no evidence of recent CI against current PHP or Doctrine versions. If you adopt it, keep it behind an application-side EntityFlusherInterface so a fixed-size array_chunk fallback or in-house flusher is a one-class change. If upstream goes stale, be prepared to vendor or fork it into your monorepo, pin it, and add tests around the import path.