Jmix 2.6 search addon using opensearch. store multiple entities(common fields from each) into one index

Support
#1

How can I store two entities: PayEntity, CheckEntity (only common fields from each) into one index (paylist-index)?
I tried with two index classes (PayIndex and CheckIndex) both pointing to the same OpenSearch index (paylist-index) with no success.

when i go to opensearch index: http://localhost:9200/paylist-index/_search
I see only similar to:

{
“took”: 27,
“timed_out”: false,
“_shards”: {
“total”: 1,
“successful”: 1,
“skipped”: 0,
“failed”: 0
},
“hits”: {
“total”: {
“value”: 1,
“relation”: “eq”
},
“max_score”: 1,
“hits”: [
{
“_index”: “paylist-index”,
“_id”: "CheckList.“0198ee6e-9e9a-705f-a31e-9c4b1b016735"”,
“_score”: 1,
“_source”: {
“_instance_name”: “..*.CheckList-0198ee6e-9e9a-705f-a31e-9c4b1b016735 [detached]”
}
}
]
}
}

How to make fields are actually being indexed (and not just _instance_name)?

One of index class:
@JmixEntitySearchIndex(indexName = “paylist-index”, entity = CheckEntity.class)
public class CheckIndex {
private UUID id;
private String number;
private LocalDate date;
private TypeEnum type;
private String name;
private BigDecimal sum;

public UUID getId() {
    return id;
}

public void setId(UUID id) {
    this.id = id;
}

public String getNumber() {
    return number;
}

public void setNumber(String number) {
    this.number = number;
}

public LocalDate getDate() {
    return date;
}

public void setDate(LocalDate date) {
    this.date = date;
}

public TypeEnum getType() {
    return type;
}

public void setType(TypeEnumtype) {
    this.type = type;
}

public String getName() {
    return payerName;
}

public void setName(String payerName) {
    this.payerName = payerName;
}

public BigDecimal getSum() {
    return sum;
}

public void setSum(BigDecimal sum) {
    this.sum = sum;
}

}

Jmix version:
Jmix version: 2.6.1
Jmix Studio Plugin Version: 2.6.2-251
IntelliJ version: IntelliJ IDEA 2025.1.2 (Ultimate Edition)

build.gradle:
implementation ‘io.jmix.search:jmix-search-flowui-starter’
implementation ‘io.jmix.search:jmix-search-starter’
implementation ‘io.jmix.search:jmix-search-opensearch-starter’

opensearch:
{
“name” : “ecc49399e008”,
“cluster_name” : “docker-cluster”,
“cluster_uuid” : “v2rik1GWTeSRXcg0171mng”,
“version” : {
“distribution” : “opensearch”,
“number” : “3.2.0”,
“build_type” : “tar”,
“build_hash” : “6adc0bf476e1624190564d7fbe4aba00ccf49ad8”,
“build_date” : “2025-08-12T03:55:01.226522683Z”,
“build_snapshot” : false,
“lucene_version” : “10.2.2”,
“minimum_wire_compatibility_version” : “2.19.0”,
“minimum_index_compatibility_version” : “2.0.0”
},
“tagline” : “The OpenSearch Project: https://opensearch.org/”
}

#4

Hi, Иса.
It is looks like you neet to create a parent entity for the two given entities. So you will be able to create an indext for this parent entity. If you need to separate the entities in the result you can do it it by processing the result of the io.jmix.search.searching.EntitySearcher#search(io.jmix.search.searching.SearchContext) method.

Is this way appropriate for you?

#5

Привет Павел. Спасибо за ответ.
В варианте с родительским entity для него нужно таблицу создать ?
Но мне желательно без создания таблицы.
С двумя интерфейсами(с одним indexName) как бы получается, но не все поля сохраняется, хотя я указал все поля. Поробовал перечислить, все равно не все поля сохраняется.

@JmixEntitySearchIndex(entity = CheckList.class, indexName = “dj-paylist-index”)
public interface CheckListIndexDefinition {

@AutoMappedField(includeProperties = { "*" })
void checkListMapping();

}

@JmixEntitySearchIndex(entity = PayList.class, indexName = “dj-paylist-index”)
public interface PayListIndexDefinition {
@AutoMappedField(includeProperties = {"", "payer."})
void payListMapping();
}

#6

Здравствуйте Иса. К сожалению дополнительную таблицу для реализации иерархии всё равно создать придётся. @MappedSuperclass использовать не получится, поскольку индексируемая сущность должна быть персистентной. Какая-либо из стратегий наследования из (SINGLE_TABLE, TABLE_PER_CLASS, JOINED) тоже для этого не подходят. Предложенный вами вариант может быть и может быть в каких-то случаях работоспособным, но это не документированное поведение, поэтому рекомендовать такое решение мы не можем. Из вариантов остаётся - использование наследование со стратегией SINGLE_TABLE или JOINED. TABLE_PER_CLASS тоже в данном случае не подойдёт из-за ограниченной поддержки EclipseLink данного варианта стратегии.

1 Like