- How do I install and set up genealabs/laravel-model-caching in a Laravel app?
- Install the package with Composer and then apply the provided Cachable trait to each Eloquent model whose queries you want cached. Once the trait is on a model, its query results are stored in your configured Laravel cache store and invalidated automatically when records are created, updated, or deleted. You can optionally publish the package config to adjust global defaults such as cache prefixing, TTL, and store selection. No repository rewrite or read-model migration is needed because the package intercepts Eloquent at the query builder level.
- Which Laravel and PHP versions does laravel-model-caching support?
- Version 13.2.x requires PHP 8.3 or newer and drops PHP 8.2 support, so Composer will pin PHP 8.2 environments to 13.1.11. That matters because a service resolving to 13.1.11 silently misses every correctness fix shipped in 13.2.0. Verify your actual PHP matrix against what Composer resolves rather than assuming, and confirm the Laravel version constraint in the package's composer.json before upgrading a major framework release.
- How does laravel-model-caching invalidate cached queries when a model changes?
- Invalidation is driven by Eloquent model events: creating, updating, or deleting a record flushes the cache entries tied to that model's key and tag set. This means any write path that bypasses Eloquent events, such as raw SQL, bulk inserts through the query builder, or writes from another service, will not trigger invalidation and can leave stale rows cached. Inventory those paths before relying on the package, and use a TTL as a safety net for anything you cannot guarantee fires events.
- How do I configure a TTL for cached model queries globally or per model?
- Version 13.2.0 makes TTL a first-class control surface with both global and per-model TTL options, and the release fixed TTL resolution so it works correctly through eager loads and is validated at both levels. Setting a TTL converts an invalidation miss from permanently stale data into data that is stale for a bounded window, which is the biggest reduction in downside risk this package has had. Pick a number the business can sign off on, and treat it as a deliberate decision rather than a default.
- Do I need to run modelCache:clear after deploying an upgrade?
- Yes. Upgrading requires running php artisan modelCache:clear after the deploy, because some queries that changed in 13.2.0 retain the old key text and could otherwise read entries written by the previous version. Skipping it opens a transient window where wrong or stale data can be served. Make this a named step with an owner in your deployment runbook, not an optional tip.
- What breaks when upgrading laravel-model-caching from 13.1 to 13.2?
- 13.2.0 ships five categories of behavioural change, including changed cache keys, changed tags, and some queries that are no longer cached at all because their keys could collide with queries returning different rows. It also removes a trait method and changes a property definition, so an untyped protected $isCachable redeclaration or a trait rule naming Cachable::newBaseQueryBuilder will cause a fatal error at class load rather than a graceful runtime degradation. Grep your models for both patterns as a pre-merge check, since a class-load fatal is a hard outage on deploy. Staying on 13.1.x to dodge the breaking changes means knowingly carrying the key-collision bug that could return wrong rows.
- Is laravel-model-caching suitable for high-write models?
- It is the right shape for read-heavy, low-write models and the wrong shape for high-write tables or cross-model derived state. Every create, update, and delete fires invalidation, so on a hot write path you pay constant cache churn and get little benefit from the cached rows. Use it selectively on models with a high read-to-write ratio, and handle derived aggregates or cross-model reporting through a separate caching or materialization strategy.
- Which cache driver should I use with laravel-model-caching?
- A tag-capable shared store such as Redis or Memcached is the practical choice, because the package's invalidation relies on grouping cached entries by key and tag sets. A standard Laravel app on Redis is the high-feasibility integration path. File or database cache stores are a poor fit for anything under real load, and per-node stores will give inconsistent results behind multiple application servers.
- Is mike-bronner/laravel-model-caching the same package as genealabs/laravel-model-caching?
- The 13.2.0 release notes reference mike-bronner/laravel-model-caching while older documentation references genealabs/laravel-model-caching. Confirm on Packagist which name is current, whether the old name still resolves or is marked abandoned, and whether any namespace change alters your composer require line. A repository or namespace move is a supply-chain governance event worth reviewing before you merge the upgrade.
- How does laravel-model-caching compare to Cache::remember or manual query caching?
- Cache::remember requires you to write, key, and invalidate cache calls by hand for every query, while this package intercepts Eloquent automatically and invalidates from model events with minimal code changes. The trade-off is transparency: you inherit the package's key and tag format as a real interface contract, which is why upgrades can break behaviour and why key-collision fixes matter. If you only need to cache a handful of expensive queries, manual Cache::remember is simpler and has no upgrade surface; if you want blanket coverage across many models, this package is the lower-effort option.