1. Introduction
Sometimes we need to connect to more than one database technology in the same application.
In this tutorial, we’ll explore the various configuration options when it comes to using multiple Spring Data modules in the same application.
Let’s use a toy Spring Boot book store to explore the topic.
2. Required Dependencies
First, we need to add our dependencies in the pom.xml file, so that we can use the spring-boot-starter-data-mongodb and spring-boot-starter-data-cassandra Spring Boot Data bindings:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-cassandra</artifactId>
<version>3.1.5</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-mongodb</artifactId>
<version>3.1.5</version>
</dependency>
3. Database Set-up
Next, we need to set up the actual databases by using pre-built Docker images of Cassandra and Mongo:
$ docker run --name mongo-db -d -p 27017:27017 mongo:latest
$ docker run --name cassandra-db -d -p 9042:9042 cassandra:latest
These two commands will automatically download the latest Cassandra and MongoDB Docker images and run the actual containers.
We also need to forward the ports (with the -p option) from inside the containers in the actual OS environment, so that our application can access the databases.
We must create the database structure for Cassandra using the cqlsh utility. Keyspace creation cannot be done automatically by CassandraDataAutoConfiguration, so we need to declare it using CQL syntax.
So first, we attach to the bash shell of the Cassandra container:
$ docker exec -it cassandra-db /bin/bash
root@419acd18891e:/# cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> CREATE KEYSPACE IF NOT exists baeldung
WITH replication = {'class':'SimpleStrategy', 'replication_factor':1};
cqlsh> USE baeldung;
cqlsh> CREATE TABLE bookaudit(
bookid VARCHAR,
rentalrecno VARCHAR,
loandate VARCHAR,
loaner VARCHAR,
primary key(bookid, rentalrecno)
);
At lines 6 and 9 we then create the relevant keyspace and table.
We could skip creating the table and simply rely on spring-boot-starter-data-cassandra to initialize the schema for us, however, since we want to explore the framework configurations individually, this is a necessary step.
By default, Mongo does not impose any kind of schema validation, so there is no need to configure anything else for it.
Finally, we configure the relevant information about the databases in our application.properties:
spring.data.cassandra.username=cassandra
spring.data.cassandra.password=cassandra
spring.data.cassandra.keyspaceName=baeldung
spring.data.cassandra.contactPoints=localhost
spring.data.cassandra.port=9042
spring.data.mongodb.host=localhost
spring.data.mongodb.port=27017
spring.data.mongodb.database=baeldung
4. Datastore Detection Mechanisms
When multiple Spring Data modules are detected on the classpath, the Spring framework enters into strict repository configuration mode. This means it uses different detection mechanisms underneath, to identify which repository belongs to which persistence technology.
4.1. Extending Module-Specific Repository Interfaces
The first mechanism tries to determine if a repository extends a Spring Data module-specific repository type:
public interface BookAuditRepository extends CassandraRepository<BookAudit, String> {
}
For the purpose of our example, the BookAudit.java contains some basic storage structure for tracking users that loaned a book:
public class BookAudit {
private String bookId;
private String rentalRecNo;
private String loaner;
private String loanDate;
// standard getters and setters
}
The same applies to the MongoDB related repository definition:
public interface BookDocumentRepository extends MongoRepository<BookDocument, String> {
}
This one stores the contents of the book and some relevant metadata about it:
public class BookDocument {
private String bookId;
private String bookName;
private String bookAuthor;
private String content;
// standard getters and setters
}
When the application context is loaded, the framework will match each repository type using the base class it is derived from:
@Test
public void givenBookAudit_whenPersistWithBookAuditRepository_thenSuccess() {
// given
BookAudit bookAudit =
new BookAudit("lorem", "ipsum", "Baeldung", "19:30/20.08.2017");
// when
bookAuditRepository.save(bookAudit);
// then
List<BookAudit> result = bookAuditRepository.findAll();
assertThat(result.isEmpty(), is(false));
assertThat(result.contains(bookAudit), is(true));
}
You can notice our domain classes are simple Java objects. In this particular situation, the Cassandra database schema must be created externally with CQL as we’ve done in section 3.
4.2. Using Module-Specific Annotations on the Domain Objects
The second strategy determines the persistence technology based on module-specific annotations on the domain objects.
Let us extend a generic CrudRepostitory and rely now on the managed objects annotations for detection:
public interface BookAuditCrudRepository extends CrudRepository<BookAudit, String> {
}
public interface BookDocumentCrudRepository extends CrudRepository<BookDocument, String> {
}
The BookAudit.java now becomes annotated with the Cassandra specific @Table and requires a compound primary key:
@Table
public class BookAudit {
@PrimaryKeyColumn(type = PrimaryKeyType.PARTITIONED)
private String bookId;
@PrimaryKeyColumn
private String rentalRecNo;
private String loaner;
private String loanDate;
// standard getters and setters
}
We choose the combination of bookId and rentalRecNo as our unique criteria since our application simply logs a new rental record each time somebody loans a book.
For the BookDocument.java we use the @Document annotation which is MongoDB specific:
@Document
public class BookDocument {
private String bookId;
private String bookName;
private String bookAuthor;
private String content;
// standard getters and setters
}
Triggering a BookDocument save with the CrudRepository is still successful, but the returned type on line 11 is now an Iterable instead of a List:
@Test
public void givenBookAudit_whenPersistWithBookDocumentCrudRepository_thenSuccess() {
// given
BookDocument bookDocument =
new BookDocument("lorem", "Foundation", "Isaac Asimov", "Once upon a time ...");
// when
bookDocumentCrudRepository.save(bookDocument);
// then
Iterable<BookDocument> resultIterable = bookDocumentCrudRepository.findAll();
List<BookDocument> result = StreamSupport.stream(resultIterable.spliterator(), false)
.collect(Collectors.toList());
assertThat(result.isEmpty(), is(false));
assertThat(result.contains(bookDocument), is(true));
}
4.3. Using Package-Based Scoping
Finally, we can specify the base packages where our repositories are defined, by using the @EnableCassandraRepositories and @EnableMongoRepositories annotations:
@EnableCassandraRepositories(basePackages="com.baeldung.multipledatamodules.cassandra")
@EnableMongoRepositories(basePackages="com.baeldung.multipledatamodules.mongo")
public class SpringDataMultipleModules {
public static void main(String[] args) {
SpringApplication.run(SpringDataMultipleModules.class, args);
}
}
As we can see in lines 1 and 2, this configuration mode assumes we use different packages for the Cassandra and MongoDB repositories.
5. Conclusion
In this tutorial, we’ve configured a simple Spring Boot application to use two different Spring Data modules in three ways.
As a first example, we extended the CassandraRepository and MongoRepository and used simple classes for the domain objects.
In our second approach, we extended the generic CrudRepository interface and relied on the module-specific annotations such as @Table and @Document on our managed objects.
In the end, we used package-based detection when we configured the application with the help of @EnableCassandraRepositories and @EnableMongoRepositories.
As always, the complete code is available over on GitHub.
