A Ruby library that maps Redis data types directly to Ruby objects with atomic operations.
Redis::Objects is a Ruby library that maps Redis data types (like counters, lists, sets, and hashes) directly to Ruby objects. It provides a high-level, Ruby-friendly API for performing atomic operations on Redis structures, solving concurrency issues that arise when using Redis with traditional ORM wrappers. It integrates seamlessly with Ruby models (e.g., ActiveRecord) while preserving Redis's atomicity guarantees.
Ruby developers building applications that require high-concurrency atomic operations on shared data, especially those using Redis for caching, counters, or real-time data structures. It's ideal for teams integrating Redis with Rails, Sinatra, or other Ruby frameworks.
Developers choose Redis::Objects because it maintains Redis's atomic operations, preventing race conditions that occur with ORM-like wrappers. It offers a clean Ruby API, automatic marshaling of complex data, and easy integration with existing models, making Redis usage more intuitive and less error-prone.
Map Redis types directly to Ruby objects
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Preserves Redis's atomicity for data types like counters and lists, preventing race conditions as emphasized in the 'Atomic Rant' philosophy section.
Easily integrates with ORMs like ActiveRecord by scoping keys to instance IDs, shown in the Team class example with redis_lock and counters.
Maps all core Redis types to Ruby objects with familiar semantics, such as array-like operations for lists and set unions/intersections.
Supports custom serializers like JSON or YAML and optional compression, detailed in the 'Custom serialization' section.
Version 2.0 introduced significant changes like renaming 'lock' to 'redis_lock' and key prefix issues, requiring code updates and manual data migration.
Tightly couples application logic to Redis, making it difficult to switch to alternative data stores without extensive refactoring of data access layers.
Nested classes (e.g., Dog::Behavior) suffer from key naming collisions that require manual migration and configuration changes, as warned in the README.