Kundera-Cassandra Отсутствие карты Compund Keys для объектов с MappedSuperClass

Question

Я работаю над отображением двух таблиц с минимальными различиями в Cassandra, однако Kundera не может правильно отобразить мою модель (я настроил ее для проверки сопоставлений с таблицами на EntityManager создание). С учетом следующего соединения ключ (структурированы в соответствии с these directions, since paging is desired и дополнительно используя Datastax Driver:

CQL таблица создает имеют следующий первичный ключ для обеих таблиц:

PRIMARY KEY ((key1, key2, key3, key4, key5, key6, key7, key8, key9, key10, key11), "clusteringKey") 

PartitionKey:

@Embeddable 
public class PartitionKey { 
    @Column 
    private key1 
    //repeat for 11 more keys 
} 

ClusteringKey :

@Embeddable 
public class ClusteringKey { 
    @Embedded 
    private PartitionKey key; 
    @Column 
    private UUID clusteringKey; 
} 

Prope rties для CQL3:

public static EntityManagerFactory getEntityManagerFactory() throws IOException { 
    if(entityManagerFactory == null) { 
     entityManagerFactory = Persistence.createEntityManagerFactory("cassandra_pu",getProperties()); 
    } 
    return entityManagerFactory; 
} 

public static Properties getProperties() throws IOException { 
    if(properties == null) { 
     properties = new Properties(); 
     properties.load(Application.class.getResourceAsStream("/application.properties")); 
     properties.put(CassandraConstants.CQL_VERSION, CassandraConstants.CQL_VERSION_3_0); 
    } 
    return properties; 
} 

Я попытался использовать две модели до сих пор.

Первый случай:

SuperRecord:

@MappedSuperClass 
public abstract class SuperRecord { 
    @EmbeddedId 
    private ClusteringKey clusteringkey; 
    //Additional Fields 
} 
//extended by StagingRecord, ProductionRecord 

Хотя сам ClusteringKey карты правильно, ничего связано с PartitionKey не отображает вообще.

В моей второй попытки:

SuperRecord:

@MappedSuperClass 
public abstract class SuperRecord { 
    //Common fields excluding keys 
} 

StagingRecord:

@Entity 
public class StagingRecord extends SuperRecord { 
    @EmbeddedId 
    private ClusteringKey key; 
} 

ProductionRecord:

@Entity 
public class ProductionRecord extends SuperRecord { 
    @EmbeddedId 
    private ClusteringKey key; 

    @Column(name="solr_query") 
    private String solrQuery; 
} 

В этой попытке, в то время как мой кластерной ке y maps, my partitionkey отображает как уникальный бинарный объект, а не его составляющие столбцы по желанию.

Что препятствует правильному отображению моего PartitionKey и как его исправить?

Edit:

После распределения суперкласса полей, я обнаружил, что @MappedSuperclass не является фактором в моем вопросе; только вложенные @Embeddeds. Кроме того, если бы мне пришлось объединять классы PartitionKey и ClusteringKey, сопоставление будет проходить проверку (хотя он не сможет правильно построить подпись метода токена в сгенерированном CQL для разбивки на страницы, так как моя модель больше не соответствует ожиданию этой функции).

Answer 1

Я пробовал с вашей первой моделью, используя следующие классы.

PartitionKey:

@Embeddable 
public class PartitionKey { 

    @Column 
    private String key1; 

    @Column 
    private String key2; 

    @Column 
    private String key3; 

    //setters and getters 

} 

ClusteringKey:

@Embeddable 
public class ClusteringKey { 

    @Embedded 
    private PartitionKey key; 

    @Column 
    private UUID clusteringKey; 

    //setters and getters 
} 

SuperRecord:

@MappedSuperclass 
public abstract class SuperRecord 
{ 
    @EmbeddedId 
    private ClusteringKey clusteringkey; 

    private String additionColumn; 

    //setters and getters 
} 

ProductionRecord:

@Entity 
public class ProductionRecord extends SuperRecord { 

    @Column(name="solr_query") 
    private String solrQuery; 

    //setters and getters 
} 

Полезная часть TestCase:

Map<String, String> props = new HashMap<>(); 
    props.put(CassandraConstants.CQL_VERSION, CassandraConstants.CQL_VERSION_3_0); 

    emf = Persistence.createEntityManagerFactory("cass_pu", props); 
    ProductionRecord pr = new ProductionRecord(); 
    pr.setSolrQuery("some solr query"); 
    pr.setAdditionColumn("col1"); 

    ClusteringKey ck = new ClusteringKey(); 
    ck.setClusteringKey(UUID.randomUUID()); 

    PartitionKey pk = new PartitionKey(); 
    pk.setKey1("k1"); 
    pk.setKey2("k2"); 
    pk.setKey3("k3"); 

    ck.setKey(pk); 

    pr.setClusteringkey(ck); 

    em.persist(pr); 

Это работает отлично.

Убедитесь, что вы включили CQL3.

Answer 2

Я столкнулся с крайним сроком, поэтому я обнаружил, что сам реализую пейджинг; модель в конечном итоге приняла форму, как первоначально указано в вопросе: SuperRecord является @MappedSuperClass для StagingRecord и ProductionRecord. Однако я объединил ClusteringKey и PartitionKey в один класс, содержащий все поля, которые фиксировали проблему сопоставления.

К сожалению, это означало, что я не мог воспользоваться функциями разбивки на страницы Кундеры, поскольку генерируемая функция CQL генерируется только с одним параметром, а не с 11 (что по дизайну, модель в вопросе предполагалась чтобы привести к правильному выпуску CQL).

В конечном счете, я реализовал подкачку самостоятельно через NativeQueries и функцию token(), вставив все необходимые поля вручную.