Redis OM Spring maps repository methods onto document indexes

A repository interface can make data access concise while leaving substantial database choices underneath it. Redis OM Spring brings that approach to JSON documents and search indexes in Redis. A Java field annotation can determine which value is indexed and how it is searched. A method declaration can then express a query whose implementation the library supplies at runtime.

The December 8 introduction presents a preview built on Spring Data Redis. It adds Java-to-JSON mapping, enhanced hash mapping and automatic search-index generation, with document repositories backed by RediSearch. The preview fills a module-integration gap described in the announcement. It does not make every repository query executable by a bare Redis server without the modules it requires.

I have used Redis since its early releases, and I like its direct relationship between operations and data structures. An object-mapping layer is useful when that relationship remains understandable. Here, the annotations are most interesting as declarations of storage and index behavior, rather than simply a way to avoid writing command calls.

The class annotation selects a storage model

The README from December 8 describes @Document as mapping Spring Data models to RedisJSON documents. This is a storage choice at class level. An identifier field uses Spring Data's @Id, while other annotations describe searchable or indexed properties.

The preview also enhances Spring Data Redis's @RedisHash mapping. Its documented enabling annotation is @EnableRedisEnhancedRepositories. That route uses RediSearch for secondary indexing of hash-based entities. The document and enhanced-hash routes therefore share some repository goals without making hashes and JSON documents the same representation.

The README's company model illustrates the document route. It includes a name, geographic point, tags and numeric properties. Some fields are indexed and others are left as ordinary stored properties. That difference is intentional. Persisting a property does not automatically mean every query over that property has a corresponding search index.

An application enables document repositories with @EnableRedisDocumentRepositories and a package selection. The preview's example then injects a repository bean and saves domain objects through it. These steps connect annotated models to repository discovery. Annotating an unrelated class outside the configured scanning scope would not be the same setup described by the example.

An index annotation selects matching behavior

The launch article distinguishes searchable names from exact-match tags. A @Searchable name becomes a text index attribute. The tags field uses a tag index attribute for exact matching. The generated schema uses a JSONPath to locate the stored value and an alias for the query attribute. That is the mechanism connecting a nested document value to a repository-level field name.

These two matching behaviors should remain distinct in application design. Full-text search interprets content through the search engine. A tag restriction selects exact tag values. Calling both fields indexed is accurate at a broad level, but omits the behavior that determines which results a query should return.

The historical README's model uses @Indexed on numeric and geographic fields as well as tags. Its introductory list uses the name @Indexable, so the concrete model is the more useful reference for the examples shown here. The preview documentation itself is still developing, which is another reason to keep examples tied to a particular revision.

I find this explicit model-to-index connection more useful than a general promise of transparent persistence. The annotation is a schema decision. A repository method can stay short because the model and server modules already supply the necessary representation and search operation.

The repository defines a query contract

The preview's RedisDocumentRepository extends Spring Data's PagingAndSortingRepository. A domain repository declares the model and identifier types through generic arguments. The framework supplies ordinary repository operations and interprets additional query methods. The following is a reduced interface excerpt following the December README's example:

public interface CompanyRepository
        extends RedisDocumentRepository<Company, String> {
    Optional<Company> findOneByName(String name);
    Iterable<Company> findByNumberOfEmployeesBetween(int lower, int upper);
}

This excerpt assumes the documented imports, mapped Company class and repository configuration. The declarations describe different result expectations. One returns an optional single company, while the other returns an iterable result for a numeric-range query. The model's indexed fields must correspond to the properties used by those methods.

The README also demonstrates geographic queries using Spring Data Point and Distance parameters. That connects a method's Near keyword to typed arguments. A method name is therefore more than a label for a handwritten implementation. It contributes information the proxy uses to derive a store-specific query.

For queries that need explicit control, the preview supports @Query and @Aggregation. Its tag example supplies a RediSearch expression and binds a named parameter through @Param. This provides another route when the interface needs to state the server query more directly. Derivation and explicit query text coexist in the documented model.

Identifier generation is another documented mapping choice. The preview README replaces the conventional UUID strategy with ULIDs for generated identifiers. The repository example still declares a string identifier type, which separates the Java type exposed to callers from the strategy that produces its value. That choice is independent of whether a name is full-text searchable or a numeric field has a range index. A model needs an identity for direct repository access as well as index definitions for its content queries.

Client abstraction does not remove module dependencies

The December README identifies RediSearch and RedisJSON as source-available modules used by advanced features. It describes self-hosting them or using an enterprise deployment that includes them. The mapper itself carries a BSD 3-Clause license. Those are separate components with separate roles, even though the Java application sees them through one library.

That separation also explains why object persistence and content queries need different implementation support. JSON mapping relies on RedisJSON's document representation. Search-backed repositories rely on index definitions and RediSearch's query execution. A successful connection to Redis alone does not demonstrate that both capabilities are present.

The preview's examples make these dependencies inspectable. The application selects document repositories, the class selects JSON mapping and field annotations select indexing. Repository methods then express the query and result shape. Keeping those choices visible lets a Spring application use the abstraction while retaining a concrete account of which server-side capabilities its methods require.