Spring Cassandra ddl-auto - spring

Question

I'm using Spring with Cassandra and I'm trying to deploy the service to an existing Cassandra DB in production, I've been reading about the ddl-auto and I'm not sure if my code will override the scheme or the data there.
These are my dependencies,
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-cassandra</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
</dependencies>
and I'm using the following to query the Repository,
import org.springframework.data.cassandra.repository.CassandraRepository;
import org.springframework.data.repository.CrudRepository;
import org.springframework.stereotype.Repository;
...
...
#Repository
public interface PostsRepo extends CrudRepository<Posts, String> {
Optional<Posts> findBypostid(String id);
}
I don't have any sql file in my project, and my application.properties file is empty.
My questions are
Do I need to define something specifically to stop/disable automatic schema creation?
Is the automatic schema creation option only applicable for embedded DB and there is nothing to worry about here?
what about spring.jpa.hibernate.ddl or spring.jpa.defer-datasource-initialization? should I set them to none and false? or not having them simply is enough?

Answer 1

Spring Data Cassandra can create the schema in Cassandra for you (Tables and Types). It is not enabled by default.
If you work with Spring Boot and the starter spring-boot-starter-data-cassandra you can use the flag spring.data.cassandra.schema-action in your application.yaml
spring:
data:
cassandra:
keyspace-name: sample keyspace
username: token
password: passwd
schema-action: create-if-not-exists
request:
timeout: 10s
connection:
connect-timeout: 10s
init-query-timeout: 10s
If you work with Spring data cassandra without Spring boot you may inherit from AbstractCassandraConfiguration and override the method getSchemaAction as described below:
#Configuration
#EnableCassandraRepositories
public class CassandraConfig extends AbstractCassandraConfiguration {
#Value("${cassandra.contactpoints}")
private String contactPoints;
#Value("${cassandra.port}")
private int port;
#Value("${cassandra.keyspace}")
private String keySpace;
#Value("${cassandra.basePackages}")
private String basePackages;
#Override
protected String getKeyspaceName() {
return keySpace;
}
#Override
protected String getContactPoints() {
return contactPoints;
}
#Override
protected int getPort() {
return port;
}
#Override
public SchemaAction getSchemaAction() {
return SchemaAction.CREATE_IF_NOT_EXISTS;
}
#Override
public String[] getEntityBasePackages() {
return new String[] {basePackages};
}
}
Multiple values are allowed for the field as described in the official Spring documentation quoted here:
SchemaAction.NONE: No tables or types are created or dropped. This is the default setting.
SchemaAction.CREATE: Create tables, indexes, and user-defined types from entities annotated with #Table and types annotated with #UserDefinedType. Existing tables or types cause an error if you tried to create the type.
SchemaAction.CREATE_IF_NOT_EXISTS: Like SchemaAction.CREATE but with IF NOT EXISTS applied. Existing tables or types do not cause any errors but may remain stale.
SchemaAction.RECREATE: Drops and recreates existing tables and types that are known to be used. Tables and types that are not configured in the application are not dropped.
SchemaAction.RECREATE_DROP_UNUSED: Drops all tables and types and recreates only known tables and types.
If the feature might be useful for your developments, it is not recommended to use it and specially in production here are my rational:
The way to implement an efficient data model with Cassandra is to design your queries first, and based on them your defined the needed tables. If 2 queries work with the same data it is recommended to create 2 tables with the same data changing the primary key. If you work with Object Mapping, (object=>Table) you may be tempted to reuse the same bean for different queries ..with the same table
Creating the schema in production will require fine tuning of the DDL requests (overriding the TTL, the compaction strategy, enabling NodeSync, special properties)
Human errors. If you let you schema-action to RECREATE...good luck.