A write-through and read-through caching library for ActiveRecord 4-6, inspired by Cache Money and cache_fu.
SecondLevelCache is a Ruby gem that implements write-through and read-through caching patterns for ActiveRecord models. It automatically caches database queries by ID or unique keys, reducing database load and improving application performance by serving cached records and keeping caches up-to-date on writes.
Ruby on Rails developers using ActiveRecord 4-6 who need transparent, automatic caching to reduce database queries and improve application performance without manual cache management.
Developers choose SecondLevelCache for its seamless integration with ActiveRecord, automatic cache invalidation, support for unique key lookups, and transaction-aware cache synchronization, providing a robust caching layer with minimal configuration.
Write Through and Read Through caching library inspired by CacheMoney and cache_fu, support ActiveRecord 4, 5 and 6.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Adds caching with minimal code changes, such as adding `second_level_cache expires_in: 1.week` to models, seamlessly fitting into existing Rails workflows.
Write-through caching ensures caches are updated on object saves and deletes, and model schema versioning auto-expires caches when columns change, maintaining consistency.
Allows fetching records by unique keys like nick_name or slugs using `fetch_by_uniq_keys`, eliminating database hits for common lookups.
Optimizes eager loading by transforming IN queries into Rails.cache.multi_read operations, reducing database load for associations as demonstrated in the README example.
Delays cache writes until after transaction commits, preventing stale cache data during atomic operations, as noted in the 'Notice' section.
Only supports find-by-ID or equal conditions queries; complex SQL strings or queries with non-primary key conditions are not cached, restricting use cases.
Cache updates happen after transaction commits, which can delay cache freshness in long-running transactions and affect real-time applications.
Requires a compatible Rails cache store like Dalli for production, adding setup complexity and potential vendor lock-in for memcached or similar systems.
While schema versioning is automatic, manual cache version changes require explicit model configuration (e.g., `version: 2`), risking oversight during updates.