- Can I use javer/influxdb-odm-bundle in a Laravel application?
- Not directly. It is a Symfony bundle that registers through Symfony Bundle classes, a DI Extension, compiler passes, and services.yaml, none of which Laravel runs. Making it work would require a fragile fork-and-bridge ServiceProvider that you would then own. The recommended path is to use the underlying InfluxDB client or ODM library behind a thin Laravel provider.
- Does javer/influxdb-odm-bundle support Laravel 10, 11, or 12?
- No. Version 1.4.0 targets Symfony 7 and PHP 8.1, not any Laravel release. The PHP 8.1 floor happens to align with Laravel 10, 11, and 12 minimums, but that is only a Composer compatibility detail, not Laravel integration. There is no Laravel service provider, facade, config publishing, or package discovery entry.
- Why doesn't javer/influxdb-odm-bundle auto-register in Laravel?
- Laravel package discovery reads extra.laravel.providers in composer.json and expects an Illuminate service provider. This bundle instead uses Symfony Bundle subclasses, a DependencyInjection Extension, prepend and CompilerPass hooks, and Symfony container configuration. Those hooks are never executed by Laravel's Illuminate container. Adding Symfony 7 support widens the Symfony version range but does not create a Laravel entry point.
- How do I install javer/influxdb-odm-bundle with Composer in a Laravel app?
- You can run composer require javer/influxdb-odm-bundle and it may resolve on Laravel 11 or 12 because Symfony 7 support reduces hard conflicts. However, it pulls symfony/dependency-injection, symfony/config, symfony/http-kernel, and related packages into vendor as unused ballast. Since nothing registers it, the package installs and then does nothing, which is worse than a clean resolve failure. Treat it as a non-starter for direct Laravel use.
- What is the best alternative to this bundle for InfluxDB in Laravel?
- Use the underlying InfluxDB client or ODM library directly and wrap it in a small Laravel service provider with a config file. For typical Laravel metrics and event use cases, writing line-protocol batches through a maintained HTTP client behind an interface is simpler and avoids an ORM abstraction. If you specifically need ODM semantics, the direct-library route is still preferred over the Symfony bundle.
- Can I use the InfluxDB ODM without the Symfony bundle in Laravel?
- Yes. Install the underlying ODM or client library and write roughly 100 to 150 lines of Laravel provider and configuration code to bind it in the container. This preserves the valuable ODM mapping layer while dropping the Symfony DI and kernel baggage. It is the preferred option when you actually need object-document mapping for time-series measurements.
- Which InfluxDB server versions does the ODM support?
- The package does not clearly document which InfluxDB server line the ODM targets, and version 1.4.0 does not address that unknown. That release is a Symfony 7 and PHP 8.1 compatibility bump plus removal of doctrine/annotations. Before adopting any part of it, verify server compatibility against the underlying ODM or client documentation.
- Is javer/influxdb-odm-bundle still maintained?
- Version 1.4.0 shows the maintainer is active and tracking Symfony 7, with PHP 8.1 as the floor and doctrine/annotations dropped. That marginally improves the abandonment picture but also confirms the roadmap is a Symfony roadmap. There is still no Laravel roadmap, entry point, or integration testing. Treat maintenance as Symfony-focused only.
- Will installing javer/influxdb-odm-bundle conflict with Laravel's dependencies?
- Symfony 7 support makes a hard Composer conflict less likely on Laravel 11 or 12 than with earlier releases. The package still drags in symfony/dependency-injection, symfony/config, and symfony/http-kernel, which are not on Laravel's typical transitive path. The realistic failure mode is a successful install followed by no runtime effect. That can slip past a composer require review if nobody checks for a Laravel provider.
- Do I have to duplicate Eloquent models to use an InfluxDB ODM in Laravel?
- An ODM implies entity or document classes, attribute mapping, and a unit-of-work-style write path. In Laravel that means either maintaining a parallel object model alongside Eloquent or mapping Eloquent models to ODM documents at every boundary. Both add ongoing maintenance tax for what is often just time-series measurement writes. Direct line-protocol batch writes usually serve those cases better than an ORM abstraction.