A bit late in the game but for the record, I am not too surprised by this behavior. And a lot of our users are not Lucene expects and won’t intuit the difference you are talking about here unless explained. That being said, I wish I had named "keyword” differently.
> On 27 Aug 2015, at 11:53, Sanne Grinovero <sa...@hibernate.org> wrote: > > 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 <gun...@hibernate.org> wrote: >> 2015-08-27 11:27 GMT+02:00 Hardy Ferentschik <ha...@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
