- How do I install darkghosthunter/rememberable-query in a Laravel app?
- Run composer require darkghosthunter/rememberable-query and register the package service provider if your Laravel version does not auto-discover it. Usage is one line per query: append remember() before get() or first(). Because the repository is archived, install it in a throwaway branch first and confirm it resolves against your Laravel and PHP versions before committing to it.
- Which Laravel and PHP versions does RememberableQuery support?
- The last tagged release is from 2022-02-16, which places verified support somewhere in the Laravel 8 to 9 and PHP 8.0 to 8.1 era. There is no published compatibility guarantee for Laravel 10, 11, or 12, or for PHP 8.2 and 8.3, and both Eloquent and cache internals have moved since then. Pin the package, run your full test suite against your target matrix, and assume patching will be required for current Laravel versions.
- How does the remember() method cache Eloquent query results?
- It exposes a remember()-style macro, and optionally a trait, on the Eloquent query builder that wraps the terminal get() or first() call in a cache-aside read. The cache key is derived from the query, and results are served from your app's configured cache store instead of hitting the database on repeat calls. No new infrastructure is needed because it reuses your existing Redis, Memcached, file, or database cache, but the caching behavior is invisible to downstream call sites.
- Does RememberableQuery automatically invalidate cached results when a model is updated?
- The package blurb advertises automatic invalidation on model changes, but you should verify how that is actually implemented before relying on it. Model writes made through Eloquent, raw SQL, queue workers, or other services often do not bust cached reads, which makes stale data the default rather than an edge case. Plan on TTL-based expiry plus an explicit forget() path, and test the write-then-read scenario yourself.
- Is darkghosthunter/rememberable-query still maintained?
- No. The GitHub repository is archived, the last release was 2022-02-16, it has roughly 48 stars and 0 dependents. Archived projects receive no CVE fixes, no framework-drift patches, and no upstream triage, so any defect becomes your responsibility. Treat it as a code snippet to vendor rather than a live, maintained dependency.
- Is it safe to use RememberableQuery in production?
- Not as a live Composer dependency without mitigation. The dominant risks are abandonment, cache-key correctness, and invalidation gaps that leave stale results; a key that omits bindings or tenant scope can serve one user's data to another, which is the highest-severity failure mode. The realistic production path is to fork or vendor the code into an internal namespace under the MIT license, or reimplement the macro over Cache::remember with an explicit, tested key builder. Both options are measured in days and preserve the one-line developer experience.
- How is the cache key generated, and can it leak results between users or tenants?
- You need to read the source to confirm exactly how the key is derived. A safe key must incorporate the full SQL, every binding value, the connection name, the locale, and any authenticated user or tenant scope; if any of those are missing, cached reads can cross tenant or user boundaries. Add a unit test that asserts two different users, or two different tenants, produce distinct keys before you adopt the package.
- Does it cache Eloquent models or plain arrays, and how are relationships handled?
- The documentation does not clearly state whether hydrated Eloquent models, collections, or plain arrays are stored. Caching full models inflates serialization time and cache-store memory, especially for large result sets, and you should also check how casts and relationships are rehydrated on read. Caching arrays or scalar rows is generally the safer and cheaper choice.
- What happens if the cache store is unavailable, and is there stampede protection?
- Confirm the behavior in testing: the safest default is to fail open to the database rather than throw, so a cache outage degrades performance instead of breaking pages. Check whether TTL jitter or atomic locks are implemented to protect hot keys from cache stampedes. If they are not, add jitter to your TTLs or wrap the read in a lock yourself.
- What should I use instead of RememberableQuery?
- The strongest alternative is to reimplement the macro yourself over Cache::remember with an explicit, testable key builder that includes tenant and auth scope. Vendoring or forking the package into something like App\Support\RememberableQuery with the MIT attribution intact is the other low-effort path and lets you add your own CI matrix. Laravel's native cache()->remember() combined with model events, or actively maintained caching packages, cover the same use case without the abandonment risk.