#java #spring #elasticsearch #spring-data #spring-data-elasticsearch
#java #весна #elasticsearch #spring-данные #spring-data-elasticsearch
Вопрос:
Ранее в версии 3 Spring Data Elasticsearch по умолчанию использовался сопоставитель Джексона, но его можно было переопределить для использования сопоставителя объектов метамодели, как описано здесь:
Я понимаю, что сопоставитель Jackson был удален в версии 4 и заменен на сопоставитель объектов Metamodel, как описано здесь:
https://docs.spring.io/spring-data/elasticsearch/docs/current/reference/html/#elasticsearch.mapping
Но, похоже, возможность переопределения средства сопоставления объектов также была удалена. Действительно ли нет способа настроить глобальный сопоставитель объектов Elasticsearch для повторного использования Jackson (или любого другого сопоставителя)? Кажется, стыдно терять гибкость, которую предоставляла эта опция.
Ответ №1:
Нет. MappingConverter используется и необходим не только для преобразования сущности в JSON и обратно, но также для преобразования и сопоставления имен полей, форматов данных и других вещей, например, при CriteriaQuery создании s или при обработке результатов поиска, таких как выделения. В Spring Data Elasticsearch есть несколько мест, где требуется информация о сопоставлении для объекта, и Джексон не может быть использован там.
Итак, в версиях до 4.0 было необходимо настроить Jackson с помощью jackson-аннотаций для объекта и других материалов с разными аннотациями, это было объединено.
Какие функции вам нужны, которые MappingConverter (реализация meta model mapper) не предлагает в сочетании с пользовательскими преобразователями?
Редактировать 05.12.2020:
допустимый момент из комментариев: должна быть возможность определить FieldNamingStrategy для объекта. Я создал проблему для этого.
Комментарии:
1. Спасибо за быстрый ответ! Ключевой функциональностью, предоставленной Джексоном, было определение стратегии именования свойств. В моем случае использования наш API использует змеиный регистр, а POJO — верблюжий, и Джексон позволяет нам легко сопоставлять форматы без необходимости указывать имя каждого отдельного поля в аннотации.
2. Итак, вы можете использовать Jackson для преобразования POJOs в ваше представление API, как это связано с тем, как Spring Data Elasticsearch сопоставляет данные?
3. Мои извинения, я должен был объяснить больше, наша цель использования Elasticsearch вообще — это фильтрация API. Мы преобразуем строку параметров в запрос соответствия для получения результатов из ES. Поскольку все наши документы индексируются с помощью полей camel case, мы не можем использовать имена полей нашего API при передаче параметра filter. Если бы мы могли настроить ES для индексации наших документов с помощью представления API, это работало бы без проблем. В противном случае нам придется добавлять аннотации @Field к сотням полей во всех наших POJO, чтобы они соответствовали именам API.
4. Я создал проблему, чтобы добавить FieldNamingStrategy в Spring Data Elasticsearch
5. Отлично, спасибо! Я ценю ответы и с нетерпением жду поддержки FieldNamingStrategy!