Doctrine Process Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for persistent, resumable process state. This is not a general workflow engine — it is the Doctrine persistence layer for the CleverAge ProcessBundle. The PM decision it informs is "do we build our own job/process state machine on top of Doctrine entities, or adopt a maintained, tested one?" For Symfony/Doctrine shops, adoption removes a meaningful chunk of custom glue (readers, writers, detachers, updaters, entity-manager resolution).
• Workflow architecture choice. It supports picking database-backed orchestration (state in Doctrine, transactional with business data, auditable, replayable) over message-bus-only choreography (Symfony Messenger). Concrete product shapes this unlocks: order fulfillment pipelines, multi-step approval chains, compliance/audit trails, nightly batch and backfill jobs, data synchronization between systems, and any process needing retry/resume/manual-intervention checkpoints.
• Feature scoping and risk framing. v3.2 is a correctness release, not a feature release. The PM-relevant changes are: entity_manager option is now actually honored across tasks (multi-EM apps behave predictably), DoctrineReaderTask hydrates entities one at a time (memory profile changes from O(result set) to O(1) — this is the difference between "safe for large tables" and "safe for small ones"), readers re-execute queries per input (no silently skipped records in multi-input jobs), DatabaseReaderTask no longer demands table when sql is supplied (fewer misconfigured jobs), and null-input cases now throw explicit errors instead of TypeError/misleading messages. Each of these is a data-integrity or operability issue, which is exactly what a PM needs to weigh when committing to a roadmap.
• Test-coverage as a go/no-go signal. Tests were added around database updater tasks on SQLite, query-builder criteria/ordering/limit/offset, reader next()-before-execution, and bundle/DI wiring. For a PM, that converts "vendor dependency" into "auditable dependency."
• Ecosystem/vendor decision point (the framing caveat). Despite being a PHP package, this is a Symfony bundle, not a Laravel package. Adopting it in a Laravel/Eloquent product is a platform decision, not a composer-require: you would be introducing Symfony's bundle/DI/kernel conventions and Doctrine ORM alongside Eloquent, or replacing Eloquent for the process domain. The PM-level question is therefore "are we willing to run a Doctrine domain next to Eloquent," not "should we install this library."
• Low adopter signal is itself a decision input. 0 stars, 0 dependents, single-vendor (CleverAge), companion bundle in a family. Treat it as internal-grade open source: fine for a team already on ProcessBundle, risky as a load-bearing dependency for a large product without a mitigation plan.

When to Consider This Package

Consider adopting when:

• You are on Symfony + Doctrine ORM, and either already use cleverage/process-bundle or are evaluating it (this bundle is meaningless without the parent — evaluate the parent first).
• You need process/task state stored transactionally with your business data, with resumability, retries, and auditability, and you want that inside the same DB rather than in a separate orchestrator.
• You run multiple EntityManagers, or use Doctrine-backed reader/writer tasks over large tables — v3.2's fixes are precisely the ones that matter in these configurations.
• The alternative is 3–6 weeks of your own engineering writing and maintaining equivalent reader/writer/detacher/updater tasks and their test suite.

Look elsewhere when:

• You are a Laravel product. Nothing here is Laravel-native. Eloquent-based models cannot be consumed by Doctrine tasks; Laravel's queue + Bus::chain/Pipeline, Horizon, or a symfony/process wrapper covers most of the same ground without a second ORM. If you truly need durable, DB-persisted state machines, evaluate Laravel-native workflow packages or keep orchestration in your own schema.
• You are not on Doctrine, or your processes are short-lived and stateless (a queue job is enough).
• You need high-throughput distributed execution, real-time monitoring/observability, or cross-language workers — the correct comparison set is Temporal, Symfony Messenger + transports, Airflow/Dagster for batch DAGs, or managed workflow services.
• You need new capabilities. v3.2 fixes defects; it does not add features. If your requirements include visual process designers, SLA timers, or rich retry policies, scope that work explicitly.
• You cannot accept bus factor risk: no external dependents means you are effectively the first real adopter, and you should budget for reading the source and possibly upstreaming patches. Mitigate with a pin + fork strategy, or decline.

How to Pitch It (Stakeholders)

Executives: "This is a small, MIT-licensed PHP library that lets our process and batch workflows keep their state in our existing database — so if a job fails halfway, it restarts where it stopped instead of from zero, and every step is auditable in the same transaction as the business data. The current release is a quality release: it fixes record-skipping in readers, memory blowups on large queries, and inconsistent database-connection handling, and it adds test coverage. Two caveats to fund around: it is built for Symfony, not Laravel, so adoption in a Laravel codebase is a platform decision rather than a drop-in; and it has essentially zero external users, so we should assume we are the first serious adopter. Recommendation: pilot it in one internal, non-revenue-critical pipeline before committing roadmap capacity."

Engineering: "This is the Doctrine integration layer for CleverAge/ProcessBundle — it gives you process tasks that read from and write to Doctrine entities, plus DBAL-backed SQL readers/writers, so process state and step logic share one ORM and one transaction boundary. If you're already on ProcessBundle, v3.2 is a must-take: entity_manager is now respected by every task instead of silently ignored (a real multi-EM correctness bug), DoctrineReaderTask hydrates one entity per iteration instead of materializing the whole result set, readers re-execute per input so no input gets skipped after a full iteration, table is only required when sql isn't set, and null inputs now fail with explicit exceptions. It also adds tests across database tasks, query-builder options, reader pre-execution, and DI wiring, and pins doctrine/dbal to ^2.9 || ^3.0 while allowing doctrine/orm 3.x. Costs to weigh: it is Symfony-kernel-coupled (services are explicit, prefixed cleverage_doctrine_process, no autowiring since v2.0), it is on a major-version cadence tied to ProcessBundle (v3 requires process-bundle ^5.0, PHP 8.5, Symfony 8), and the global_flush writer option and PurgeDoctrineCacheTask no longer exist. In a Laravel context, treat it as a deliberate Doctrine domain island with its own kernel wiring — price that, including the migration effort, before agreeing to it."