Supporto per keyspace multipli per repository spring-data-cassandra?

Question

Spring Data Cassandra supporta repository di chiavi multiple nello stesso contesto applicativo? Sto installando la configurazione dei dati molla cassandra utilizzando la seguente classe JavaConfig

@Configuration 
@EnableCassandraRepositories(basePackages = "com.blah.repository") 
public class CassandraConfig extends AbstractCassandraConfiguration { 

@Override 
public String getKeyspaceName() { 
    return "keyspace1"; 
} 

Ho cercato di creare una seconda classe di configurazione dopo aver spostato le classi repository a un pacchetto diverso.

@Configuration 
@EnableCassandraRepositories(basePackages = "com.blah.secondrepository") 
public class SecondCassandraConfig extends AbstractCassandraConfiguration { 

@Override 
public String getKeyspaceName() { 
    return "keyspace2"; 
} 

Tuttavia in tal caso il primo set, se non riescono repository come la famiglia di colonna configurato per i soggetti non si trova nello spazio delle chiavi. Penso che probabilmente stia cercando la famiglia di colonne nel secondo spazio delle chiavi.

spring-data-cassandra supporta repository di chiavi multiple? L'unico posto in cui ho trovato un riferimento per più spazi chiavi è stato here. Ma non spiega se questo può essere fatto con i repository?

Answer 1

Prova nominare esplicitamente i CassandraTemplate fagioli per ogni spazio delle chiavi e l'utilizzo di quei nomi nel attributo @EnableCassandraRepositories del annotazioni cassandraTemplateRef (vedi linee con /* CHANGED */ per le modifiche).

Nella prima configurazione:

@Configuration 
@EnableCassandraRepositories(basePackages = "com.blah.repository", 
    /* CHANGED */ cassandraTemplateRef = "template1") 
public class CassandraConfig extends AbstractCassandraConfiguration { 

@Override 
public String getKeyspaceName() { 
    return "keyspace1"; 
} 

/* CHANGED */ 
@Override 
@Bean(name = "template1") 
public CassandraAdminOperations cassandraTemplate() throws Exception { 
    return new CassandraAdminTemplate(session().getObject(), cassandraConverter()); 
} 

... e nella tua seconda configurazione:

@Configuration 
@EnableCassandraRepositories(basePackages = "com.blah.secondrepository", 
    /* CHANGED */ cassandraTemplateRef = "template2") 
public class SecondCassandraConfig extends AbstractCassandraConfiguration { 

@Override 
public String getKeyspaceName() { 
    return "keyspace2"; 
} 

/* CHANGED */ 
@Override 
@Bean(name = "template2") 
public CassandraAdminOperations cassandraTemplate() throws Exception { 
    return new CassandraAdminTemplate(session().getObject(), cassandraConverter()); 
} 

penso che potrebbe fare il trucco. Si prega di postare indietro se non lo fa.

Answer 2

Sembra che sia consigliabile utilizzare nomi di spazi chiavi completi nelle query gestite da una sessione, in quanto la sessione non è molto leggera.
Si prega di vedere riferimento here

Answer 3

Ho provato questo approccio. Tuttavia mi sono imbattuto in eccezioni mentre provavo ad accedere alla famiglia di colonne 2. Le operazioni sulla famiglia di colonne 1 sembrano andare bene.

Sto indovinando perché il bean CassandraSessionFactoryBean sottostante è un singleton. E questo fa sì che non configurato columnfamily columnfamily2

Qui ci sono alcuni più registri per fornire un contesto

DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Tornando un'istanza memorizzata nella cache di fagioli Singleton 'EntityManagerFactory' DEBUG org.springframework .beans.factory.support.DefaultListableBeanFactory - Tornando un'istanza memorizzata nella cache di fagioli Singleton 'session' DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Tornando un'istanza memorizzata nella cache di fagioli Singleton 'grappolo'

org.springframework.cassandra .sup port.exception.CassandraInvalidQueryException: columnfamily shardgroup non configurato; l'eccezione annidata è com.datastax.driver.core.exceptions.InvalidQueryException: non configurato columnfamily2 columnfamily a org.springframework.cassandra.support.CassandraExceptionTranslator.translateExceptionIfPossible (CassandraExceptionTranslator.java:116) a org.springframework.cassandra.config.CassandraCqlSessionFactoryBean. translateExceptionIfPossible (CassandraCqlSessionFactoryBean.java:74)

Answer 4

Hmm.Non posso commentare la risposta di matthew-adams. Ma questo riutilizzerà l'oggetto della sessione come AbstractCassandraConfiguration è annotato con @Bean su tutti i getter pertinenti.

In una configurazione simile, inizialmente avevo lavorato con la sovrascrittura di tutti i getter e in particolare i nomi dei bean. Ma a causa della primavera continua a pretendere di aver bisogno di fagioli con i nomi. Ora ho dovuto fare una copia di AbstractCassandraConfiguration senza annotazioni che posso ereditare.

Assicurarsi di esporre CassandraTemplate in modo da poterlo consultare da @EnableCassandraRepositories se si utilizzano tali.

Ho anche un'implementazione separata di AbstractClusterConfiguration per esporre un comune CassandraCqlClusterFactoryBean in modo che le connessioni sottostanti vengano riutilizzate.

Modifica: Immagino che secondo il thread di posta collegato da bclarance si debba davvero tentare di riutilizzare l'oggetto Session. Sembra il modo primavera dati Cassandra non è realmente impostato per che anche se

Answer 5

lavoro APP Esempio: http://valchkou.com/spring-boot-cassandra.html#multikeyspace

L'idea è necessario sostituire i fagioli di default: SessionFactory e template

Esempio:

1) application.yml

spring: 
    data: 
    cassandra: 
     test1: 
     keyspace-name: test1_keyspace 
     contact-points: localhost 
     test2: 
     keyspace-name: test2_keyspace 
     contact-points: localhost 

2) classe base config

public abstract class CassandraBaseConfig extends AbstractCassandraConfiguration{ 
    protected String contactPoints; 
    protected String keyspaceName; 

    public String getContactPoints() { 
     return contactPoints; 
    } 
    public void setContactPoints(String contactPoints) { 
     this.contactPoints = contactPoints; 
    } 

    public void setKeyspaceName(String keyspaceName) { 
     this.keyspaceName = keyspaceName; 
    } 
    @Override 
    protected String getKeyspaceName() { 
     return keyspaceName; 
    } 
} 

3) attuazione Config per test1

package com.sample.repo.test1; 

@Configuration 
@ConfigurationProperties("spring.data.cassandra.test1") 
@EnableCassandraRepositories(
     basePackages = "com.sample.repo.test1", 
     cassandraTemplateRef = "test1Template" 
) 
public class Test1Config extends CassandraBaseConfig { 

    @Override 
    @Primary 
    @Bean(name = "test1Template") 
    public CassandraAdminOperations cassandraTemplate() throws Exception { 
     return new CassandraAdminTemplate(session().getObject(), cassandraConverter()); 
    } 

    @Override 
    @Bean(name = "test1Session") 
    public CassandraSessionFactoryBean session() throws Exception { 

     CassandraSessionFactoryBean session = new CassandraSessionFactoryBean(); 

     session.setCluster(cluster().getObject()); 
     session.setConverter(cassandraConverter()); 
     session.setKeyspaceName(getKeyspaceName()); 
     session.setSchemaAction(getSchemaAction()); 
     session.setStartupScripts(getStartupScripts()); 
     session.setShutdownScripts(getShutdownScripts()); 

     return session; 
    } 
} 

4) stesso per test2, basta usare pacchetto differente pacchetto com.sample.repo.test2;

5) luogo di pronti contro termine per ogni spazio delle chiavi nel pacchetto dedicato cioè

package com.sample.repo.test1; 

@Repository 
public interface RepositoryForTest1 extends CassandraRepository<MyEntity> { 
// .... 
} 


package com.sample.repo.test2; 

@Repository 
public interface RepositoryForTest2 extends CassandraRepository<MyEntity> { 
// .... 
}