Rememberable Laravel Package

Getting Started

• Install the beta explicitly and pin it: composer require amelia/rememberable:3.0.0-beta1. The release note does not state supported Laravel/PHP versions, so re-check Composer constraints instead of carrying forward the old Laravel 5 assumption.
• Register the service provider if it is not auto-discovered, and publish/read any config. Look for defaults for TTL, cache store, key prefix, and an enable/disable switch.
• Read the trait and config before applying it broadly. v3.0.0-beta1 changes the usage model: the release note says caching is automatic once the trait is added to a base model. Confirm the exact namespace, cache-key generation, invalidation hooks, and whether older methods like remember()/dontRemember() still exist.
• Start in staging with a narrow base model, not the application-wide base model:

class CachedBaseModel extends Model
{
    use Amelia\Rememberable\Rememberable;
}

class Product extends CachedBaseModel
{
}

• First use case: run a normal read query and verify that the second call hits cache:

$products = Product::where('active', 1)->orderBy('name')->get();

Run it twice in php artisan tinker with DB::listen(fn ($q) => dump($q->sql)). The second call should emit no SQL. Do not roll out to a global base model until you can prove hits, misses, and invalidation.

Implementation Patterns

• Treat automatic caching as global behavior. If the trait lives on a base model, every subclass query inherits caching. Roll out behind staging first, then one model family, then the shared base model. Keep a config/env kill switch if the package provides one.
• Verify TTL policy from config/source. The release note does not document defaults. Establish TTLs by data class: short for dashboards and filtered lists, longer for reference data, and avoid permanent caching unless invalidation is explicit.
• Assume reads are cached automatically; writes are not automatically invalidated. Wire saved/deleted observers or a repository layer to forget affected keys, flush tags, or bump a version segment embedded in the key.
• Use tags only where supported. If the package exposes tags, Redis/Memcached gives the cleanest invalidation pattern: cache by tag, flush the tag in model events. File/database cache stores will not support this.
• Namespace by tenant/user. Confirm that automatic keys include tenant-scoped SQL or configured prefixes. If not, use explicit key overrides where available or avoid enabling auto-cache for multi-tenant models until keys are proven isolated.
• Eager-load before the cached query executes. Call with() before get()/paginate() so relations are part of the cached payload rather than firing uncached on every request.
• Paginate conservatively. Automatic caching may cache every paginator page including metadata. Keep page sizes sane and verify page number is part of the key.
• Provide a bypass. Support and incident response need a way to force fresh reads: config flag, per-query disable method if it still exists, or a documented temporary env toggle.
• Centralize audit points. Even with automatic caching, put cache-sensitive reads behind query objects/repositories where invalidation is documented beside the read path.
• Test with query counts. Use the array cache, flush between tests, and assert with DB::enableQueryLog() that cached reads emit zero queries and writes invalidate as expected.

The release note says “automatic query caching” but does not document method names, config keys, or invalidation behavior. Confirm the v3 API against source before standardizing it.

Gotchas and Tips

• Beta + sparse release notes = verify everything. This is a major beta release with a one-line note. Re-check provider registration, config publishing, PHP/Laravel constraints, and whether the old explicit remember() API was removed or retained.
• Automatic caching is a broad behavioral change. Adding the trait to a base model can silently cache every query in the app. Start narrow, measure hit rates, and keep a rollback path.
• Stale data remains the default failure mode. Automatic query caching does not mean automatic write-through invalidation. Every cached model needs an invalidation strategy for create/update/delete and bulk operations.
• Transactions and cache. Do not persist cached results before commit. Invalidate after commit (DB::afterCommit or model events) so rolled-back rows do not remain cached.
• Cache-key length and collisions. SQL-derived keys can exceed Memcached limits or collide across similar queries. Log generated keys in development and hash/prefix long keys if the package allows customization.
• Tags need the right driver. Confirm CACHE_DRIVER per environment; file and database stores may throw when tags are used.
• Serialization traps. Cached Eloquent results are serialized. Closures, API resources, and non-serializable attributes can break round-trips; prefer cached collections/arrays.
• Builder reuse. Cache results, not builder instances. Create fresh builders per request and avoid mutating cached builder state.
• Debugging recipe. Prove hits with DB::listen, Redis INFO, or a temporary zero TTL. If you cannot demonstrate a cache hit, assume the query is uncached or the key is changing.
• Extension point. The trait or key-generation method is still the seam: override it to customize namespacing/versioning, or wrap it in a base model so the whole app follows one caching policy.
• Consider the alternative. If v3 beta’s automatic caching is the draw, weigh beta stability against watson/rememberable or a small first-party trait. For a one-line release note, budget time for source review before production adoption.