4.1.4 Writing Cassandra Repository

As you saw in chapter 3, writing a repository with Spring Data involves simply declaring an interface that extends one of Spring Data’s base repository interfaces and optionally declaring additional query methods for custom queries. As it turns out, writing Cassandra repositories isn’t much different.

In fact, there’s very little that you’ll need to change in the repositories we’ve already written to make them work for Cassandra persistence. For example, consider the following IngredientRepository we created in chapter 3:

package tacos.data;

import org.springframework.data.repository.CrudRepository;

import tacos.Ingredient;

public interface IngredientRepository
  extends CrudRepository<Ingredient, String> {
}

By extending CrudRepository as shown here, IngredientRepository is ready to persist Ingredient objects whose ID property (or, in the case of Cassandra, the primary key property) is a String. That’s perfect! No changes are needed for IngredientRepository.

The changes required for OrderRepository are only slightly more involved. Instead of a Long parameter, the ID parameter type specified when extending CrudRepository will be changed to UUID as follows:

package tacos.data;

import java.util.UUID;

import org.springframework.data.repository.CrudRepository;

import tacos.TacoOrder;

public interface OrderRepository
    extends CrudRepository<TacoOrder, UUID> {
}

There’s a lot of power in Cassandra, and when it’s teamed up with Spring Data, you can wield that power in your Spring applications. But let’s shift our attention to another database for which Spring Data repository support is available: MongoDB.