| @Yoann Rodière All right, perfectly reasonable, thanks for the quick answer. I did not think of the issues that would arise from relaxing these rules. I will try the solution you suggested. As for the date format - I am also sticking to the default format and the lack of format flexibility is not a blocking issue. You can reject this issue if it's not useful. @Guillaume Smet In short: In my Hibernate entity mapping I store epoch timestamps instead of dates, in order to be timezone-agnostic. My ES index has to contain these values in 'date' format because I will need to use date math in the future. My Elasticsearch index is custom-built, and the mapping is not generated by Hibernate Search. I started integrating with ES in parallel with your team and created a very custom-tailored Elasticsearch infrastructure and mapping before looking at the Hibernate Search integration. I also did my own integration to communicate with my cluster directly, so I have freedom to do whatever I want. However, near-real-time syncing the my ES cluster to my database, while respecting the transaction boundary and doing batching of ES requests is not a trivial thing. Especially if I have to do it outside of the ORM layer... So right now I am trying to use Hibernate Search for that, and adapt my ES index to what it is compatible with. I am not planning to use Hibernate Search for querying at all, only syncing data. |