Solarium Fixtures Laravel Package

Technical Evaluation

What it is: A small PHP library that applies the Doctrine Data Fixtures pattern to Apache Solr. It provides a fixtures interface plus a loader that purges an index and pushes documents through Solarium's update API, so developers can seed a Solr core with known documents for tests, local development, or demo environments. It is a developer-tooling package, not a runtime dependency of the search path.

Architecture fit: The design is intentionally thin — an interface consumers implement (returning Solarium update queries or document objects), a loader that orchestrates purge → load → commit, and optionally a console command. That is a good shape for us: the coupling surface is Solarium's UpdateQuery/Client API, not our application. However, it is built for the Symfony/standalone-PHP world, not Laravel. There is no service provider, no config publication, no facade, and no Laravel-native console wiring. In a Laravel codebase it would be an unmanaged Composer dependency invoked from a hand-written artisan command.

Integration feasibility: Mechanically easy — composer require, implement the fixture interface, register a command. Real feasibility depends on two constraints we must verify before committing:

1. Solarium major version alignment. The package predates Solarium 6/7. Solarium's client construction, endpoint handling, and update/commit semantics changed across majors. If the package pins solarium/solarium:^3|^4, we either downgrade Solarium (unacceptable if we use Solarium elsewhere) or maintain a fork.
2. PHP runtime. Constraint sets from that era typically cap below PHP 8.1+. Expect to widen composer.json constraints and validate against PHP 8.2/8.3.

Technical risk: High on maintenance, low on blast radius. The zero-star / zero-dependent signal, combined with no visible release cadence, means we should treat this as abandoned source code we adopt, not a dependency we consume. The mitigating factor is size: the useful logic is a few hundred lines, so the fork cost is a day or two, not a quarter. Risk is also naturally bounded because the package should never run against production indexes.

Key questions to answer in the spike:

• What Solarium and PHP versions does composer.json actually allow, and does the code run unmodified on our target runtime?
• Does it support SolrCloud / collection aliases, or only single-core standalone endpoints?
• How does it handle commit strategy — per-batch, single terminal commit, or optimize? Commit behavior dominates fixture-load wall time.
• Does the purge step delete by query (*:*) with a hard commit, and is there any environment guardrail preventing a misconfigured endpoint from wiping a shared index?
• Is the license compatible with our distribution model?
• Is there an existing, maintained alternative (raw Solarium, or a Laravel Scout Solr driver) that makes this package redundant?

Verdict: Viable as a reference implementation to copy or fork. Not viable as a long-term pinned dependency.

Integration Approach

Stack fit: Poor out of the box, acceptable with a thin adapter. Laravel already owns console commands, configuration, and environment handling; this package owns none of that. The pragmatic integration is: depend on solarium/solarium directly, vendor the fixture loader (or fork it under our namespace), and expose one artisan command, e.g. solr:fixtures:load --class=... --env=local, that resolves fixtures from the container and refuses to run outside permitted environments. Do not attempt to bolt on Symfony console/bundle pieces.

Migration path:

1. Spike (1–2 days): stand up Solr in Docker, install the package unmodified, load a 1k-document fixture set, record timings and failure behavior.
2. Decide: if the spike is clean and Solarium constraints match ours, wrap it. If not, port the loader (~200–300 LOC) into app/Support/Solr/Fixtures/ and drop the dependency. Given the adoption signals, the port is the likely outcome and is cheap.
3. Harden: add environment allowlist, endpoint validation (assert the target core name matches an expected pattern before purge), and structured logging.
4. CI: run fixture load as a job step against an ephemeral Solr container to seed integration tests.

Compatibility: Pin Solarium explicitly and treat this package's constraints as advisory only after verification. Add a composer why-not check in CI. Confirm PHP 8.2/8.3 with static analysis (PHPStan level 5+) on the forked code, since upstream has no CI to lean on.

Sequencing: Do this after the core search integration is chosen and working. Fixtures are an accelerant for testing and local dev; they are not on the critical path for shipping search. If the team is still evaluating Solr vs. another engine, defer entirely — this package only makes sense once Solarium is the confirmed client.

Operational Impact

Maintenance: Effectively full ownership. Budget a named owner, a fork in our VCS, and a documented "we forked this, here is why" note. Expected ongoing cost is low (a few hours per year plus Solarium upgrade work), but the upgrade work is real: each Solarium major will require revalidating the loader.

Support: No upstream support channel, no security response, no issue triage. Acceptable only because this is dev/test tooling with no production runtime exposure. That containment must be enforced, not assumed.

Scaling: The loader is inherently serial and commit-bound. Fixture sets in the low tens of thousands of documents are fine with batched updates and a single terminal commit; beyond that, wall time is dominated by Solr commit and the package offers no parallelism. It is not a bulk-reindex tool — use Solr's Data Import Handler, post tool, or a queue-backed indexer for production-scale loads.

Failure modes to design against:

• Destructive purge against the wrong endpoint — the highest-severity risk. Mitigate with an environment allowlist, core-name assertion, and a --dry-run default.
• Silent schema mismatch — documents with unknown fields are dropped or rejected depending on update.chain; fixtures "load successfully" with fewer docs than expected. Add a post-load count assertion.
• Partial load on timeout — a mid-run failure leaves a partially populated index; make the command idempotent via purge-then-load and fail loudly.
• Solarium API drift — an unpinned Solarium upgrade breaks the loader at runtime, typically in CI. Pin and test.
• No transactionality — a failed run cannot be rolled back; recovery is re-running.

Ramp-up: Low. A developer familiar with Solarium or Doctrine fixtures is productive in half a day; someone unfamiliar needs about a day, most of which is Solr concepts (cores, commit, schema) rather than this package. Document the fork decision and the environment guardrails in the repo README so ramp-up stays at that level.