алиасинг с пружинными данными, поиск в хранилище данных и поиск конфликтов - PullRequest
1 голос
/ 17 марта 2019

У меня возникли проблемы с конфликтом псевдонимов с использованием Spring-Data-ES,

Мне нужен ежедневный индекс переворачивания - A_Day1, A_Day2, ... A_now() с псевдонимами:

1. active_A - points to latest index - A_now()
*Persistence should be done on this alias*
2. search_A - points to all existing indexes + A_now()
*Search should be done on this alias*

Моя сущность документа содержит indexName для search_A, @Document(indexName = "search_A", indexType="..."), Это приводит к тому, что каждый раз при выполнении поискового запроса либо через репозиторий (findBy ....), либо через ElasticTemplate.queryForPage (Query, Clazz.class) выполняется поиск по этому псевдониму - и, таким образом, поиск по всем существующие индексы, , который работает как ожидалось.

Проблема возникает на постоянном -

Используя репозиторий spring-data-es, я сохраняю сущности во всем жизненном цикле документов.

repository.save(Entity)

Spring-data-es будет сканировать indexName и persist, то есть постоянство теперь относится к псевдониму (search_A) , а НЕ к псевдониму active_A - не работает должным образом .

Я думал о нескольких обходных решениях , которые не являются изящными и расточительными ИМО:

  1. Переопределить шаг save () в моем DAO - затем перед вызовом repository.save - измените значение аннотации во время выполнения на псевдоним персистентности, затем после сохранения - измените его снова для поиска псевдонима.
  2. Измените @Document (indexName = # {dynamicDailyBased ()}), используя пружинный SPEL, но тогда я все еще застрял с необходимостью псевдонима для поиска. так как Spring-Data-ES будет нуждаться в indexName для поиска.
  3. Переопределить все поиск происходит в одном месте - затем с помощью .withIndices ("псевдоним") -> это заставит меня потерять все пружины самозаключения -> тонн кода шаблона.

Подобная проблема выявляется здесь - Как взаимодействовать с упругим поиском Псевдоним с использованием данных Spring но я ищу решение, которое не переопределяет / делает пользовательскую реализацию, так как это было бы слишком много, чтобы не использовать данные методы хранилища.

Поиск лучшего решения, если это возможно, или понимание, чтобы изменить мой дизайн / идею:)

1 Ответ

1 голос
/ 25 марта 2019

Я думаю, что третий способ самый элегантный, просто нужно сделать это весной.

Создайте новый класс AbstractElasticsearchRepositoryEx, который расширяет AbstractElasticsearchRepository, а затем зарегистрируйте его как переопределенный базовый класс для репозиториев ES в файле конфигурации:

<elasticsearch:repositories base-package="com.amco.db.repository.elasticsearch" base-class="com.amco.db.repository.elasticsearch.AbstractElasticsearchRepositoryEx"/>

Теперь мы можем переопределить любой метод репозитория, который мы хотим расширить логикой, например, спасти(). Внутри мы могли бы определить, какой тип Документа мы получили в этом методе, и выбрать способ выполнения - особенный для этого Документа, который должен быть постоянным с использованием псевдонима active_A и обычным для любого другого.

Вот ссылка на официальную документацию по этому поводу: https://docs.spring.io/spring-data/elasticsearch/docs/current/reference/html/#repositories.customize-base-repository

...