Using Hibernate Search filters with Elasticsearch

sedooe · **Joined:** Mon Nov 06, 2017 6:17 am **Posts:** 2

First of all thanks for the work you've done!

According to: https://docs.jboss.org/hibernate/stable ... /#_filters

Code:

    @Override
    public String getJsonFilter() {
        return "{ 'term': { 'name': '" + name + "' } }";
    }

I wonder why we have to return JSON string here, instead Query? You already have converters from Hibernate Query DSL to Elasticsearch JSON query, so why can't we benefit from it in filters?

What is the technical restriction for it, if there is any?

sanne.grinovero · **Posted:** Tue Nov 07, 2017 5:58 pm

hi again :)

technically you're right, the Query API could work in most cases.

But while today we have converters from Query to the Elasticsearch JSON counterpart, we created these converters only to make it easier for people on the current (previous) API to start using Elasticsearch.

We can't actually convert any type of Lucene Query, as people could possibly write their own sophisticated Query implementations and then we'd be unable to convert them correctly. Only by allowing people to write the JSON directly we can allow you to write the most advanced and custom queries, so its possible that in future we'll deprecate the Query<>JSON conversion, while the new APIs which we introduce - like this one - are already taking this into account.

I hope that addresses your question? I guess that for many simple cases we could also provide something simpler, but it's important that advanced users don't get stuck either.

I'd be happy to consider alternative proposals!

sedooe · **Joined:** Mon Nov 06, 2017 6:17 am **Posts:** 2

sanne.grinovero wrote:

hi again :)

technically you're right, the Query API could work in most cases.

But while today we have converters from Query to the Elasticsearch JSON counterpart, we created these converters only to make it easier for people on the current (previous) API to start using Elasticsearch.

We can't actually convert any type of Lucene Query, as people could possibly write their own sophisticated Query implementations and then we'd be unable to convert them correctly. Only by allowing people to write the JSON directly we can allow you to write the most advanced and custom queries, so its possible that in future we'll deprecate the Query<>JSON conversion, while the new APIs which we introduce - like this one - are already taking this into account.

I hope that addresses your question? I guess that for many simple cases we could also provide something simpler, but it's important that advanced users don't get stuck either.

I'd be happy to consider alternative proposals!

Thanks for the clear explanation :)