Odm Bundle Laravel Package

Getting Started

Read this first: silpo-tech/odm-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, and no Eloquent-style API. A Laravel developer can still use the underlying ODM library, but the bundle's autoconfiguration and DI extensions are inert outside Symfony. Confirm what you're actually getting before installing:

composer show silpo-tech/odm-bundle --all
# Then read composer.json's "require" block and src/

The single most important thing to check is whether the bundle wraps Doctrine MongoDB ODM (doctrine/mongodb-odm) or a bespoke in-house ODM. That determines everything about how you'd use it day-to-day.

Minimal first steps (Symfony host):

1. composer require silpo-tech/odm-bundle
2. Register the bundle in config/bundles.php (SilpoTech\OdmBundle\... per the README).
3. Look in DependencyInjection/Configuration.php and Resources/config/ for the config tree and service IDs — this is where the actual knobs live.
4. Define one Document, persist it, read it back. That is the fastest way to prove the wiring works.

First use case: a small MongoDB-backed aggregate (e.g., an audit log or product catalog document) where you persist a plain PHP object through a DocumentManager and query it through a generated repository. If that path doesn't work end-to-end in under an hour, stop — the package is not mature enough to build on.

Reality check: 0 stars, 0 dependents, score 0.03, brand-new release. Treat this as an internal Silpo utility that leaked to Packagist, not a community package. Budget time for reading source.

Implementation Patterns

In a Symfony app (intended use): rely on the bundle's DI wiring. Autowire the ODM's manager/repository services, annotate or attribute your Document classes, and let the bundle supply the client/config. Use it the way you'd use DoctrineBundle: configure connection in config/packages/*.yaml, then inject managers into services, commands, and message handlers. Keep documents as thin data holders and put behavior in services.

In a Laravel app (manual integration): you are reimplementing the bundle's DI extension by hand. The pattern is a small service provider that:

// app/Providers/OdmServiceProvider.php
public function register(): void
{
    $this->app->singleton(DocumentManager::class, function ($app) {
        $client = new Client($app['config']['database.mongodb.uri']);
        return DocumentManager::create($client, $app['config']['odm'] ?? []);
    });
}

Then bind repositories or resolve $dm->getRepository(MyDocument::class) per call. Skip the bundle entirely in this case — install the underlying ODM library directly and avoid a dependency you can't use.

Repository/service pattern: wrap the ODM in your own repository interfaces so controllers and jobs never touch the manager directly. This is the only way to keep ODM-specific types out of your domain and to make the code testable if you later swap the package out.

Queues and console: persist documents from jobs/commands by injecting the manager into the handler. Watch for connection lifecycle in long-running workers — recreate or ping the client between jobs.

Testing: point the manager at a disposable test database (or an in-memory Mongo-compatible substitute if supported) and clean collections between tests. Do not mock the DocumentManager; mock your own repository interfaces instead.

Gotchas and Tips

• Symfony-only by design. Installing it in Laravel gives you classes but no wiring. The DependencyInjection/ and Resources/config/ code simply won't run. Decide early whether you're porting the config or dropping the bundle.
• Zero dependents is a warning, not a badge. There is no community usage to validate edge cases. Pin the version, vendor-review the source, and check the release cadence before betting a feature on it.
• Version constraints bite. A fresh bundle (release 2025-10-03) is likely pinned to recent PHP/Symfony/Doctrine majors. Run composer why-not early if your app is on an older stack.
• ODM ≠ ORM. There are no migrations. Schema changes are implicit, and index creation is manual or via a command. Plan index management explicitly; don't assume it happens for you.
• ObjectId vs. string IDs. Serializing documents to JSON or passing IDs across layers usually requires conversion. Normalize IDs at your boundaries (requests, jobs, API resources) rather than sprinkling casts.
• Config quirks live in Configuration.php. The YAML key names and defaults are not documented in the README. Read that file before writing config; guessing produces silent no-ops.
• Debugging in Symfony: bin/console debug:container --tag=doctrine_mongodb.odm.document_manager (or the bundle's own tag) and debug:config <bundle_alias> confirm what actually got registered. In Laravel, php artisan tinker plus app(DocumentManager::class) is your equivalent smoke test.
• Extension points to look for: custom Doctrine types for value objects, event subscribers (prePersist/preUpdate) for timestamps and auditing, and custom repository classes. These are usually the only seams the bundle offers — confirm they exist before designing around them.
• Exit criteria: if the README doesn't explain configuration, there are no tests in tests/, and the source is a thin wrapper over Doctrine, use Doctrine MongoDB ODM directly. You lose nothing and gain a maintainable dependency.