- Is florianajir/rabbitmq-sql-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. It ships a Symfony DI Extension, Configuration tree, and compiler passes, none of which register automatically in Laravel's service container. There is no bundle registration mechanism in Laravel, so it will not autowire or boot the way a Laravel package would. Treat it as a Symfony component, not a drop-in Laravel dependency.
- Can I install florianajir/rabbitmq-sql-bundle in a Laravel 10 or 11 app?
- Almost certainly not without dependency surgery. Its Composer constraints date from May 2016, targeting PHP 5.6/7.0-era, Symfony 2.7/3.0-era, and contemporary Doctrine, so resolution against a Laravel 10/11 app on PHP 8.2 will likely fail. Using --ignore-platform-reqs is a trap rather than a workaround because it bypasses the checks that would otherwise stop incompatible runtime code from loading. A viable install requires a fork with re-declared constraints.
- What does florianajir/rabbitmq-sql-bundle do, and what problem does it solve?
- It bridges RabbitMQ and a relational SQL database inside Symfony. It consumes messages from RabbitMQ queues and persists them into SQL-backed tables using Doctrine-managed storage, with configurable queue, connection, and table mapping options. The value proposition is broker throughput plus durable, queryable SQL records. The core persistence logic is tied to Doctrine ORM metadata and entity mappings, which have no direct Eloquent equivalent.
- Does florianajir/rabbitmq-sql-bundle support PHP 8.2 and modern Laravel versions?
- No, not as published. The package predates typed properties and modern php-amqplib APIs, and its 2016 idioms raise runtime risk on PHP 8 around null handling and exception signatures. There is no declared support for PHP 8.2, Laravel 10/11, MySQL 8, Postgres 15/16, or RabbitMQ 3.13 features such as quorum queues and publisher confirms. Assume incompatibility until you prove otherwise in a fork.
- Is florianajir/rabbitmq-sql-bundle still maintained?
- No. There has been no release in roughly nine years, with no CI, no security policy, and no visible issue triage. It has negligible validation at about 2 stars and 0 dependents, and the bus factor is one with no upstream to escalate to. That means transitive dependency CVE exposure is unknown and unpatchable without a fork.
- What Laravel alternatives exist for consuming RabbitMQ messages into SQL?
- Compose the capability rather than installing this bundle. Use a maintained RabbitMQ bridge such as vladimir-yuldashev/laravel-queue-rabbitmq, or drive php-amqplib directly inside a long-running artisan command. Persist with Eloquent models and explicit belongsTo/hasMany relations wrapped in DB::transaction, and handle reliability with ShouldQueue plus failed_jobs or an explicit dead-letter exchange. That gives you Laravel-native observability and retries.
- Can I fork florianajir/rabbitmq-sql-bundle and remove the Symfony and Doctrine parts?
- You can, but weigh the cost. Strip the bundle scaffolding, keep the persistence writer, and re-map Doctrine metadata to Eloquent; that is feasible but leaves you owning abandoned code. It is cheaper only if the relationship graph is genuinely intricate. For a scoped first consumer, reimplementing the design on Laravel primitives is usually the better path.
- How should I persist RabbitMQ messages into a SQL database in Laravel?
- Consume in a long-running artisan command or queue worker, deserialize the message envelope, and write it inside a DB::transaction. Define Eloquent models with explicit relations, store an idempotency key or message ID with a unique index, and decide whether you need relationship-aware persistence or just an append-only table plus a projection job. Add retries, failed_jobs, and a dead-letter path so poison messages do not loop.
- Does florianajir/rabbitmq-sql-bundle integrate with Laravel queues, Horizon, or failed_jobs?
- No, not natively. It is a Symfony bundle with its own RabbitMQ producer/consumer workflow and does not plug into Laravel's queue abstraction, Horizon, or failed_jobs table. You would have to bridge those concerns yourself, which is one of the main reasons to rebuild on Laravel primitives instead. Any integration would be custom glue in a fork.
- What are the production and security risks of adopting florianajir/rabbitmq-sql-bundle?
- High. Unmaintained code with unknown transitive CVE exposure, no security policy, no CI, and a single maintainer means you cannot patch upstream and have no escalation path. The 2016 client generation predates current RabbitMQ and database features, so subtle runtime failures are plausible on modern PHP. Adopting it transfers an unbounded maintenance liability for a few hundred lines of consumer orchestration, which is why the recommendation is to treat the repository as a reference implementation.