- How do I install and configure codewithdennis/laravel-model-cache in Laravel?
- Install it with Composer using composer require codewithdennis/laravel-model-cache, then publish the package config file and apply the provided caching trait to the models you want to cache. The package is designed to integrate at the Eloquent layer, so existing query code can benefit without moving logic into controllers. Because the current release is v1.0.0-beta.1, treat the config schema and trait API as unstable until 1.0.
- Which Laravel and PHP versions does laravel-model-cache support?
- The package targets a conventional Laravel application on PHP 8.x, but the exact Laravel major version constraints should be checked in its composer.json and CI matrix before adoption. The beta release does not include descriptive release notes, so do not assume support for every current or older Laravel version. Verify the constraints against your application's framework and PHP versions as part of your evaluation.
- How does the warmup / forever cache differ from TTL-based caching?
- Warmup lets you run a heavy query once and store the result in a forever cache, which suits read-heavy reference data that changes rarely. TTL-based caching stores model query results for a configured lifetime and is better when some staleness is acceptable but data does change. With either mode, you still need a deliberate invalidation or refresh strategy for writes that bypass Eloquent.
- Does laravel-model-cache invalidate cached results when a model is updated or deleted?
- Automatic cache handling implies model events are used to invalidate entries on normal Eloquent saves and deletes, but the beta documentation does not prove coverage for mass updates, upsert, soft deletes, pivot changes, or raw query builder writes. Those operations may bypass model events, leaving stale cached results. Test every write path for each cached model, and avoid caching models that are mutated by DB::table calls, queue workers, or third-party sync jobs until invalidation behavior is confirmed.
- Which cache driver should I use with laravel-model-cache: Redis, file, or database?
- Use a shared cache backend such as Redis or Memcached rather than the file or array driver, especially if you run multiple workers or servers. Cache tags are not supported by every Laravel cache driver, and the package's fallback behavior on database, file, and array stores is not documented here. Confirm tag support and invalidation behavior on your chosen driver before caching production models.
- How does laravel-model-cache handle multi-tenancy and per-user query scopes?
- Cache keys must include tenant and user scope, but the package's key strategy is not documented in the available context and should be treated as unverified at beta. If you cache tenant-scoped or per-user queries, either confirm that the trait incorporates those scopes into keys or avoid using it for that data. A key collision across tenants would be a serious data leak, so test isolation explicitly.
- Is laravel-model-cache safe to use with Laravel Octane and queued jobs?
- Under Laravel Octane, long-lived workers make correct invalidation and shared cache storage more important, so use Redis or Memcached and verify that cached entries are not held in process memory. For queued jobs, beware of invalidation happening before a database transaction commits, which can produce stale reads. Test Octane and transaction scenarios directly rather than assuming the beta package handles them.
- How do I test models that use laravel-model-cache?
- In tests, use Laravel's cache fakes or a test cache driver and assert that queries are cached and invalidated as expected for each model. Also test mass updates, deletes, transaction rollbacks, and any raw database writes that touch cached tables. The package's own test coverage and static analysis level are unknown from the beta release notes, so your application tests are the main safety net.
- Is laravel-model-cache production-ready at v1.0.0-beta.1?
- Treat v1.0.0-beta.1 as pre-stable: the public API, configuration schema, and cache-key strategy may change before 1.0. The package also appears to be single-maintainer with no stated support commitment, which is a bus-factor risk for a dependency that affects data correctness. Pilot it on one or two low-risk, read-heavy models where brief staleness is tolerable rather than applying the trait globally.
- What are alternatives to laravel-model-cache for caching Eloquent queries?
- The main alternatives are Laravel's built-in Cache::remember around specific queries, repository-level caching that you control, and other model-caching packages with more mature invalidation documentation. The right choice depends on how much invalidation correctness you can verify and whether you want a centralized model-layer cache or explicit caching at query boundaries. For beta adoption, explicit Cache::remember is often the lower-risk starting point.