Lada Cache Laravel Package

Getting Started

1. Installation

   composer require spiritix/lada-cache
   php artisan vendor:publish --provider="Spiritix\LadaCache\LadaCacheServiceProvider"
   

   Add LadaCacheTrait to a base model or directly to models:

   use Spiritix\LadaCache\Database\LadaCacheTrait;
   
   class BaseModel extends Model
   {
       use LadaCacheTrait;
   }
   

2. Enable in .env

   LADA_CACHE_ACTIVE=true
   LADA_CACHE_DEBUGBAR=true  # Optional: for Debugbar integration
   

3. First Use Case Immediately start seeing cached queries. Test with:

   php artisan lada-cache:flush  # Clear cache for testing
   

   Verify via Debugbar (if enabled) or by checking Redis keys.

Implementation Patterns

1. Transparent Caching Workflow

• No manual cache calls: All Eloquent/Query Builder queries are auto-cached.
• Example:

  // Automatically cached
  $users = User::where('active', true)->get();
  $count = User::count();
  

2. Fine-Grained Control

• Exclude tables in config/lada-cache.php:

  'exclude_tables' => ['sensitive_data', 'logs'],
  

• Disable per-request (e.g., admin actions):

  \Spiritix\LadaCache\Facades\LadaCache::disable();
  // Critical operations...
  \Spiritix\LadaCache\Facades\LadaCache::enable();
  

3. Debugging & Monitoring

• Debugbar Integration: Visualize cache hits/misses/invalidations.
• Console Commands:

  php artisan lada-cache:flush      # Clear all cache
  php artisan lada-cache:disable    # Temporarily disable
  php artisan lada-cache:enable     # Re-enable
  

4. Multi-Connection Support

• Use DB::connection('foo')->getPdo() for non-Lada connections.
• Models with $connection property work automatically.

5. Custom Redis Connection

• Configure lada-cache.redis_connection in .env:

  LADA_CACHE_REDIS_CONNECTION=custom_redis
  

6. Invalidation Strategies

• Auto-invalidation: Triggers on insert, update, delete, or truncate.
• Manual invalidation (e.g., after bulk operations):

  \Spiritix\LadaCache\Facades\LadaCache::invalidate(['users', 'posts']);
  

Gotchas and Tips

Pitfalls

1. Composite Primary Keys

   • Falls back to table-level invalidation if not a single-column PK.
   • Fix: Ensure models use simple primary keys (e.g., id).

2. Raw SQL Bypasses Cache

   • Avoid DB::select("RAW SQL") or DB::statement().
   • Workaround: Use Query Builder or Eloquent.

3. Third-Party Query Builders

   • Custom query builders may bypass Lada.
   • Fix: Extend Spiritix\LadaCache\Database\Query\Builder for integration.

4. Debugbar Conflicts

   • Ensure fruitcake/laravel-debugbar is installed (v6.x+).
   • Fix: Run composer require fruitcake/laravel-debugbar.

5. Pessimistic Locks Bypass Cache

   • lockForUpdate()/sharedLock() queries are not cached.
   • Tip: Use cautiously in read-heavy apps.

6. Large Payloads

   • Caching 500MB+ queries won’t improve performance (Redis memory overhead).
   • Tip: Cache smaller datasets or use pagination.

Debugging Tips

• Check Redis Keys:

  redis-cli KEYS "lada:*"
  

• Enable Verbose Logging:

  LADA_CACHE_LOG_QUERIES=true
  

• Inspect Debugbar Tab: Shows cache stats per query.

Performance Quirks

• Warm-Up Phase: First request after flush may be slower.
• Tag Healing: Cache tags self-heal on hits (idempotent SADD).
• Non-Blocking Flush: Cache::flush() uses UNLINK by default.

Extension Points

1. Custom Reflector Override Spiritix\LadaCache\Database\Reflector to handle edge-case SQL.

2. Event Listeners Listen to lada.cache.invalidated or lada.cache.missed:

   \Event::listen('lada.cache.invalidated', function ($tags) {
       Log::debug("Invalidated tags: " . implode(', ', $tags));
   });
   

3. Connection Binding Bind custom drivers via DB::extend():

   DB::extend('custom', function ($config) {
       return new \Spiritix\LadaCache\Database\Connection($config);
   });
   

Configuration Tricks

• Short-Lived Cache:

  'default_expiration' => 60, // 1 minute
  

• Exclude Specific Models:

  'exclude_tables' => ['password_resets', 'failed_jobs'],
  

• Disable for CI:

  LADA_CACHE_ACTIVE=${LADA_CACHE_ACTIVE:-false}
  

Common Fixes

```markdown
---
**Note**: Always test in a staging environment before deploying to production, especially when toggling cache settings or invalidating large datasets.