Influxdb Data Fixtures Bundle Laravel Package

Getting Started

This bundle is a thin bridge: it lets Nelmio Alice parse fixture files into InfluxDB ODM documents and then persists them through the ODM's document manager. It is not a full fixtures framework, so the first thing to establish is which versions of Alice, the ODM, and the InfluxDB client it was built against.

Install and register

composer require --dev javer/influxdb-data-fixtures-bundle:^1.2

As of v1.2.0 the package requires PHP 8.1+ and supports Symfony 7. If your app is still on PHP 8.0 or Symfony 5, Composer will resolve an older 1.x tag instead — check the constraints in vendor/javer/influxdb-data-fixtures-bundle/composer.json before installing, and confirm the resolved nelmio/alice and InfluxDB ODM versions are compatible with the rest of your stack. Register the bundle in config/bundles.php, usually for dev and test only:

Javer\InfluxDBDataFixturesBundle\JaverInfluxDBDataFixturesBundle::class => ['dev' => true, 'test' => true],

Configure the connection

The bundle does not manage the InfluxDB client itself; it consumes the ODM/document-manager service. Configure your InfluxDB host, port, database/bucket, and credentials through the ODM bundle's configuration (or directly in services.yaml if you wire the client manually). Keep credentials in .env/.env.test, e.g. INFLUXDB_URL, INFLUXDB_DATABASE.

Where to look first

1. README.md — if present, it usually contains the fixture file path and loader service id.
2. CHANGELOG.md / GitHub releases — v1.2.0 is a maintenance release (Symfony 7, PHP 8.1 floor, CI updates) with no documented API changes, so behavior should match earlier 1.x.
3. src/DependencyInjection/Configuration.php and Extension.php — the real config tree and extension alias.
4. src/Resources/config/services.yaml — the loader service id, aliases, and what it is autowired against.
5. src/ for the loader/persister classes — often a class implementing Alice's LoaderInterface or wrapping DataLoader.
6. composer.json — the actual compatibility contract (PHP, Symfony, Alice, ODM).

First use case

Seed a local or CI InfluxDB bucket with representative time-series data so dashboards, aggregations, and query tests have something to read. Put fixtures in something like fixtures/influxdb/dev.yaml, then load them either with the bundle's console command (check src/Command/) or by injecting the loader into a small app command:

$loader->load(['fixtures/influxdb/dev.yaml']);

Confirm the exact service id and method signature from services.yaml; do not assume the loader is public.

Implementation Patterns

Map fixtures to ODM documents

Alice fixtures are keyed by the document class. The class must carry whatever measurement/annotation metadata your InfluxDB ODM requires:

App\Document\Measurement:
  measurement_1:
    device: sensor-1
    temperature: <numberBetween(18, 24)>
    time: <dateTimeBetween('-1 day', 'now')>

Use Alice generators (<numberBetween()>, <randomFloat()>, <dateTimeBetween()>) for realistic values and timestamps. For time series, ranges are the workhorse:

App\Document\Measurement:
  measurement_{1..500}:
    device: <randomElement(['sensor-1', 'sensor-2', 'sensor-3'])>
    temperature: <randomFloat(2, 15, 30)>
    time: <dateTimeBetween('-7 days', 'now')>

References across documents

Alice supports object references, which is useful when a point belongs to a device:

App\Document\Device:
  device_1:
    name: sensor-1

App\Document\Measurement:
  measurement_1:
    device: '@device_1'

In InfluxDB tags are strings, so verify that the ODM serializes the referenced object correctly (via __toString() or an explicit tag property). If not, use a plain string and keep references only for related SQL-style entities.

Split fixtures by environment

Keep fixtures/influxdb/base.yaml, dev.yaml, and test.yaml. Load base first, then the environment file. This mirrors Alice's normal layering and avoids duplicating shared measurements.

Integrate with tests

Wrap fixture loading in your test bootstrap or a base TestCase:

protected function setUp(): void
{
    $this->loader->load(['fixtures/influxdb/test.yaml']);
}

protected function tearDown(): void
{
    // Drop the measurement/bucket or delete series written by the test
}

Use a dedicated test bucket/database and a unique name per run where possible. InfluxDB has no unique constraints, so cleanup is your responsibility. On Symfony 6.2+/7 the test.service_container still works for fetching the (typically private) loader; on older Symfony use kernel->getContainer()->get(...) against the test container or alias the service in config/services_test.yaml.

Batch and chunk

For large ranges, persist in chunks rather than building one enormous in-memory array. If the bundle exposes a batch size, set it; otherwise load multiple smaller files or wrap the loader and flush per file. Watch memory with ranges above a few thousand objects. v1.2.0 did not announce persister changes, so any earlier chunking behavior should carry over unchanged.

Custom Alice providers

If you need InfluxDB-specific values — nanosecond epoch timestamps, tag sets, line-protocol escaping — implement an Alice ProviderInterface or processor and register it with the loader. This keeps fixture files declarative and avoids PHP code inside YAML.

Use in CI

Run an ephemeral InfluxDB container, wait for readiness, load fixtures once, then run the suite. On PHP 8.1/Symfony 7 runners the 1.2.x tag is the right choice; pin the minor (^1.2) so CI does not silently pick up an unreviewed 1.3. Keep fixtures deterministic (seed Faker if available) so aggregation assertions are stable.

Gotchas and Tips

Low adoption, still treat it as vendored code

v1.2.0 is a maintenance release, not evidence of a broader maintenance commitment — the package remains a thin, low-star bridge. Pin ^1.2, read the loader source before building workflows on top of it, and be prepared to fork or patch (MIT-licensed, small surface area).

PHP 8.1 and Symfony 7 floors

If your app is on PHP 8.0 or Symfony 5.4, Composer will downgrade you to an earlier 1.x tag. That is fine functionally, but keep your lockfile honest: check composer show javer/influxdb-data-fixtures-bundle in CI and avoid assuming 1.2-only behavior. On Symfony 7, verify the bundle's DI extension doesn't rely on removed ContainerBuilder/service APIs at load time by running a cold cache:clear.

Alice version mismatch is the most likely failure

Nelmio Alice 3.x changed loader APIs and the Symfony bridge. The v1.2.0 notes do not mention an Alice or ODM bump, so the previously supported range likely stands — but if you are upgrading Symfony alongside this package, Composer may resolve a newer Alice. Check composer.json and run a minimal load before wiring it into CI.

Schema-on-write and field type conflicts

InfluxDB determines field types on first write. If one fixture writes temperature: 21 (float) and another writes temperature: "21" (string), subsequent writes can be rejected. Keep generator types consistent across all fixture files for the same field.

Timestamps and precision

Alice produces DateTime objects; the ODM/client must convert them to the precision you configured (seconds, milliseconds, nanoseconds). Timezone drift between Faker's default and the client's expectation will silently shift points. Assert one known timestamp end-to-end.

Rerunning duplicates data

There is no idempotency. Loading the same fixture twice doubles your points unless you clear the measurement, drop the series, or recreate the bucket. Make cleanup part of the load command or test lifecycle.

Reference ordering

Cross-file references require the referenced file to load first. Alice will fail with an unresolved reference otherwise. Keep dependency order explicit in the file list.

Private services in the container

The loader is likely private. In tests use the test container (test.service_container) or alias the service as public in config/services_test.yaml (public aliasing still works in Symfony 7, but prefer the test container). In commands, inject the loader via constructor rather than pulling from the container.

InfluxDB 1.x vs 2.x

Database + retention policy versus bucket + org/token are not interchangeable. Confirm which client API the ODM uses and configure accordingly; a wrong mode often surfaces as an authentication or "database not found" error rather than a clear config error.

Debugging

Dump the parsed objects before persistence to separate Alice problems from ODM problems. Inspect written data with the influx CLI or a SELECT/Flux query rather than assuming a successful flush means correct tags and fields. Enable Alice logging if the loader supports it. After upgrading to 1.2.0, re-run one fixture load end-to-end and diff a small query result against the pre-upgrade output — the release is low risk but CI-only changes can mask a dependency resolution shift.

Extension points

The cleanest customization seams are an Alice provider/processor for value generation, a decorator around the loader for chunking or cleanup, and a custom persister if you need to control write precision or batching. Avoid editing vendor code; the MIT license and small surface area make a fork practical if the package stalls.