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, Sa
> Agreed on the name being sub-par for that usage pattern most of us
> apparently have in mind. So yes, if there was another uniformly-to-use
> method for equality I wouldn't mind limiting the current one to string
> fields.
Cool
--Hardy
___
hibernate-
On Thu, Aug 27, 2015 at 11:34:19AM +0100, Sanne Grinovero wrote:
> Regarding "strong reason", my doubt is just that the method seems
> wrong for the purpose: keyWORD(), and it seems to imply we override an
> explicit user choice.
Right. I also think some sort of understanding is necessary. Obvious
On Thu, Aug 27, 2015 at 10:53:29AM +0100, Sanne Grinovero wrote:
> 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 u
> > 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
2015-08-27 12:34 GMT+02:00 Sanne Grinovero :
> On 27 August 2015 at 11:07, Gunnar Morling wrote:
>> 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.
On 27 August 2015 at 11:07, Gunnar Morling wrote:
> 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.
Right we can't just change behaviour currently, e
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
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
2015-08-27 11:27 GMT+02:00 Hardy Ferentschik :
> 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
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
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?
Thanks,
Sanne
___
hibernate-dev mailing list
12 matches
Mail list logo
