Yetisearch Laravel Package

Technical Evaluation

Architecture fit: YetiSearch 2.6.1 remains a strong fit for Laravel/PHP applications that want embedded SQLite FTS5 search without adding external search infrastructure. It supports external-content and own-content indexes, stemming, chunking, fuzzy terms, spatial data, and batch indexing. The new YetiSearch::stemmingFor($index) API improves observability of language/stemming configuration and is useful for admin diagnostics, index metadata screens, and configuration validation.

Integration feasibility: The release is primarily a correctness and resilience update rather than a major API change. It fixes several serious production issues: corrupted external-content indexes created by 2.5.x prefix deletes, stale chunks when documents shrink, duplicate document IDs in batches, nested transaction failures, and deletion failures on indexes created with enable_spatial => false. These fixes materially improve production suitability for Laravel apps that write search indexes inside application transactions or use chunked documents.

Technical risk: Risk is concentrated in upgrade behavior, not in normal greenfield adoption. Existing indexes built by 2.5.x may contain field-name tokens from the old FTS5 rebuild behavior. 2.6.1 can heal these on first write, but the first write to a large affected index may trigger a full FTS rebuild and take the write lock. The transaction/savepoint changes improve safety when callers already have a transaction open, but teams should validate rollback semantics in their application flows. SQLite’s single-writer model remains the main scalability constraint. Platform-specific SQLite math-function gaps on Windows are partially mitigated, but location searches against missing spatial tables can still fail.

Key questions:

• Which Laravel, PHP, and SQLite versions are officially supported and tested for 2.6.1?
• Are target indexes external-content, own-content, spatial-enabled, or chunked, and which prior YetiSearch versions created them?
• What is the expected index size and write concurrency profile?
• Should production upgrade proactively run rebuildFts() on known 2.5.x external-content indexes, or rely on first-write healing?
• What is the rollback plan if a first-write rebuild is slow or fails under load?
• Are there application transactions that wrap index writes, and have savepoint behavior and rollback paths been tested?
• Does the team need stemmingFor() exposed in admin tooling or configuration checks?

Integration Approach

Stack fit: Best suited to Laravel/PHP services already using SQLite as an application or dedicated search database, especially small-to-medium datasets where operational simplicity matters. It is less suitable for high-write-throughput, multi-service, or horizontally scaled search workloads that need an external search cluster.

Migration path: Treat 2.6.1 as a recommended upgrade for any deployment on 2.5.x, 2.6.0, or earlier where external-content indexes have received prefix deletes. Sequence should be: back up the SQLite database; update Composer dependency to 2.6.1; clear Laravel config/cache; run the application test suite against a restored database copy; run rebuildFts() in staging for affected external-content indexes; smoke-test writes, updates, deletes, prefix deletes, chunked document rewrites, transaction-wrapped writes, and searches for former field-name tokens such as title; then deploy with monitoring.

Compatibility: Verify the package’s supported Laravel/PHP/SQLite matrix and FTS5 availability. Confirm whether indexes are external-content or own-content, because healing behavior differs. Confirm spatial configuration: indexes with enable_spatial => false should now delete correctly, but hand-dropped spatial tables still affect location-filtered searches. YetiSearch Pro uses a separate metadata key and is not touched by the new healing key, so mixed Pro/non-Pro environments need explicit validation.

Sequencing: Upgrade in staging first, not directly in production. If indexes are known to be healthy and built by 2.6.x, a normal Composer update and smoke test may suffice. If indexes were built by 2.5.x, plan a maintenance window or off-peak deployment because the first write may rebuild the FTS table. Avoid deploying during heavy ingestion. After deployment, monitor first writes and search errors, then schedule cleanup or rebuild of any remaining legacy indexes.

Operational Impact

Maintenance: 2.6.1 reduces long-term maintenance burden by making indexes self-healing and by fixing delete/update edge cases. The new fts_built_by metadata key gives operational traceability for index build version, though teams should not depend on it as a public API. The detailed release notes are useful but also signal complexity; operators need a runbook for index rebuilds, backups, and legacy-index remediation.

Support: Package supportability improves because transaction handling now joins caller transactions via savepoints and no longer rolls back the caller’s outer transaction. The stemmingFor() method is a small but useful support/diagnostic feature. The truncated compatibility note in the release should be reviewed in full before upgrade, especially around the 2.6.0 advice for rebuildFts() after prefix deletes on external-content indexes.

Scaling: SQLite remains the limiting factor. The first-write healing path takes a write lock and rebuilds the FTS table for affected external-content indexes, so large legacy indexes can cause slow writes or lock contention. Normal search traffic does not trigger the rebuild. Chunked documents and batches are handled more correctly, but high-volume ingestion should still be batched and scheduled carefully. Spatial and fuzzy features add write amplification.

Failure modes: Main risks are malformed legacy indexes if healing is interrupted, slow first writes on large indexes, SQLite lock contention, and failed rebuilds surfacing as StorageException. The release states failed rebuilds roll back and leave the key unset so the index is not written in a damaging state, but operations should still alert on write failures and search errors containing “database disk image is malformed.” Deletes on spatial-disabled indexes are fixed, but location searches on indexes with missing spatial tables can still fail. Transaction rollback behavior should be tested for application code that wraps index writes.

Ramp-up: Teams familiar with Laravel and SQLite can adopt the package quickly, but production ownership requires understanding FTS5 external-content behavior, stemming, chunk IDs, spatial tables, and transaction/savepoint semantics. Allocate time for a staging upgrade rehearsal, especially if indexes predate 2.6.x. Provide engineers with a clear rollback path: restore database backup, pin previous package version, and rebuild indexes if needed.