[hibernate-dev] Search DSL expectations for "keyword()" clause

[Gunnar Morling]

Is there any strong reason for not supporting this on numeric fields?
Assuming the remaining corner cases can be fixed (null handling
mainly?), my vote goes for keeping the current behaviour.

I suppose many people don't think in the technical terms of
"TermQuery" or "NumericRangeQuery" but just in terms of the data they
want to look for. Different methods to be used based on the field type
will make things harder for them. Also consider potential future
alternative backends of the query DSL (ES) where string/numeric/date
match queries can be handled uniformly.


2015-08-27 11:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> For the record, Gustavo replied forgetting to CC the list stating that
> he would expect it to produce a valid NumericRangeQuery, and that
> seems to be the expectation of Adrian too, gauging at some code he
> wrote.
>
> That surprised me. I'm personally feeling more comfortable with
> Hardy's answer, as I'm looking at "keyword()" as something which
> explicitly demands for a TermQuery.
>
> However the current DSL implementation will have this produce a valid
> NumericRangeQuery - except in some corner cases I'm working on - so I
> don't think we can change this in a minor release, not least as the
> HQL parser and downstream projects rely on this.
>
> There is an open issue caused by the fact that the current
> implementation isn't consistent as it fails to recognize the field as
> Numeric when it's wrapped by one of the other FieldBridge decorators
> (a simple instanceof isn't safe for such purposes).
>
> So.. questions:
>
> 1# Deprecate?
> I'll have to fix the inconsistency for now and make it produce a
> working query in all cases... but do we want to deprecate this and
> have it produce a WARN to state that you really shouldn't use a
> keyword() on numeric fields?
>
> 2# Alternatives?
> If we decide that keyword() should not be abused for this and will be
> deprecated, should we give an alternative method like
> "exactEqualsQuery()" to provide a flexible alternative (working with
> either keyword, number, null tokens).
>
> Thanks,
> Sanne
>
>
>
> On 27 August 2015 at 10:36, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 2015-08-27 11:27 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>>> On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
>>>> Assuming you build a Lucene Query the following way:
>>>>
>>>>     queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>>>>
>>>> What is your expectation, if the "age" field is being indexed as a NumericField?
>>>
>>> I would say that this throws an exception. At least atm. Numeric encoded
>>> fields needs to be targeted by a range query. One could imagine to transparently
>>> create a range query in this case. I guess by the metadata we could tell that we have
>>> a numeric field. However, that's a a lot of magic then, in particular since we
>>> always that that a keyword query maps to a TermQuery.
>>
>> Hum, but that's already happening, no?
>>
>> See DSLTest.testUseOfFieldBridge() where we do exactly that:
>>
>>     monthQb.keyword().onField( "monthValue" ).matching( 2 ).createQuery();
>>
>> Internally it's creating a NumericRangeQuery with start/end set to the
>> same value.
>>
>> If the field uses a null encoding bridge, it'd be a String field,
>> though, if I am not mistaken (unless we use some numeric null encoding
>> as discussed recently), so a simple TermQuery query would be the right
>> thing.
>>
>>
>>>
>>> --Hardy
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev