Connections Bundle Laravel Package

Getting Started

This bundle is archived and is part of the retired ONGR platform. Treat it as legacy code you are adopting, not as a modern dependency. The published line is 0.8.x (latest: 0.8.1), and 0.8.1 is a dependency-constraint release only — it bumps the required ongr/elasticsearch-bundle to ~0.9. There are no new features and no deprecations to plan around. Before anything else:

1. Pin both packages, exactly. The 0.8.x line targets Symfony 2.x and PHP 5.5/5.6-era APIs, and 0.8.1 explicitly requires ongr/elasticsearch-bundle: ~0.9. Do not expect it to install on Symfony 4/5+, PHP 7.4+, or PHP 8. If your project is not already on that stack, stop here.

   composer require "ongr/connections-bundle:0.8.1" "ongr/elasticsearch-bundle:~0.9"
   

2. Install and register. Register ONGR\ConnectionsBundle\ONGRConnectionsBundle in AppKernel (or bundles.php), then import @ONGRConnectionsBundle/Resources/config/services.yml if your app doesn't auto-load it.
3. Read the source, not the docs. The README is thin and the wiki-style docs on the ONGR site are gone. Your first stop is vendor/ongr/connections-bundle/Resources/config/*.yml (service/command wiring) and Command/ — that is where the actual contracts live.
4. Define one connection. The bundle models a source (e.g. Doctrine/MySQL) and a target (e.g. Elasticsearch) plus a pipeline that moves records between them. Start with the smallest config: a single source, a single target, a single pipeline name, and no transformers.
5. First use case: a full sync from relational data to an Elasticsearch index. Run the bundle's sync command in --dry-run/verbose mode first, confirm the pipeline resolves both endpoints, then run it for real against a throwaway index.

If you are starting a greenfield project, the only correct "getting started" step is: do not start with this bundle. Use ongr/elasticsearch-bundle directly (also archived but better documented) or a current Elasticsearch client and write your own sync command.

Implementation Patterns

Connection as a configuration unit. Each connection is defined under the bundle's connections config key with a source service, a target service, and a pipeline. Keep one connection per source→target pair; you will spend less time debugging when you can name the failing connection in a log line.

ongr_connections:
    connections:
        product_sync:
            source: app.doctrine.product_provider
            target: app.elasticsearch.product_indexer
            pipeline: product_pipeline

Pipeline as the transformation seam. Treat the pipeline as the place where extraction, mapping, and indexing happen, and keep business logic out of the bundle's service definitions. In practice you implement small services that conform to the imports the bundle pulls in (an extractor, a transformer, an indexer) and point the pipeline at them. This is the extension point the bundle was designed around — use it, rather than subclassing the bundle's internal classes.

Drive syncs from console, not from HTTP. The bundle's value is its sync commands. Wire them into cron:

app/console ongr:connections:sync product_sync --env=prod

and into deployment (full reindex) versus incremental (schedule delta syncs). Always have a full-sync path that can be re-run idempotently.

Treat the ESB coupling as part of your API. Because 0.8.1 pins ongr/elasticsearch-bundle ~0.9, the indexer/target services you configure are ESB 0.9 services, not modern Elasticsearch client objects. When you wrap them in your own services, wrap behind your own interface so a future replacement of ESB doesn't ripple through your pipeline code.

Event hooks for side effects. If the bundle dispatches sync lifecycle events, hook them for cache invalidation, metrics, or alerting rather than editing bundle internals. Because the code is abandoned, event wiring is safer to keep in your services than in the bundle.

Dependency injection overrides. When you need to change behavior, prefer defining your own service and referencing it in config instead of overriding the bundle's service id. Overriding internal ids breaks on any patch and there will be no upstream fixes.

Integration tip — test with a disposable index. Point the target at a --suffix-able index name per environment so CI can run syncs without touching production. The bundle has no concept of environments; build that in your app config.

Gotchas and Tips

• Unmaintained and archived. No security patches, no PHP/Symfony compatibility work. Every other caveat below is a consequence of this one. Budget for replacing it, not for living with it.
• 0.8.1 is a constraint bump, not a fix. The only change is elasticsearch-bundle ~0.9. That means upgrading the bundle can force an ESB upgrade (and vice versa). Pin both, commit the lockfile, and expect a resolver conflict if any other package wants a different ESB range.
• Version compatibility is the biggest trap. The 0.8.x releases target old elasticsearch-php and Symfony 2.x APIs. A modern Doctrine DBAL, newer Elasticsearch client, or PHP 7+ runtime will fail in ways that look like bundle bugs but are version skew. Check composer.json in the vendor directory before debugging anything else.
• Thin documentation. Search results and blog posts from 2014–2015 are mostly dead. Debugging means reading Resources/config and command classes; treat the source as the spec. Release notes are one line long — read the commit, not the changelog.
• Zero dependents / one star is a real signal. You will not find Stack Overflow answers, and there is no upstream maintainer to ask. Anything you fix, you keep.
• Command debugging. Run sync commands with -vvv and watch container compilation, not just the command output — most "nothing happened" issues are a misconfigured service id silently resolved to a stub.
• Config quirks. Service ids referenced in connection config are resolved at container compile time. Typos often fail late (at command runtime) rather than at boot; add a smoke test that boots the connection service in CI.
• Extension points are fragile. Classes you extend or services you override can change between the handful of 0.8.x patches. Pin exact versions and commit your lockfile.
• Migration path. If this is greenfield or long-lived, plan the exit now: either replace it with a small custom sync command against a current Elasticsearch client, or move to a maintained data-pipeline tool. The bundle's only genuine selling point was ONGR platform integration, and that ecosystem is gone — so the cost/benefit no longer favors it.
• Use it only if: you are maintaining an existing legacy ONGR application where it already works, and you need to make a bounded change. Do not introduce it into new code.