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

[Hardy Ferentschik]

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 use a
> keyword() on numeric fields?

+1 (Personally I could even imagine to throw an exception with a clear
message on which type of query should be used.  I don't see that as a contract
break).

> 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).

That's my thinking as well. We already have this distinction between numeric 
and non numeric types via the .range() entry point vs all the rest. 
I would opt for 'numericEquals' or just 'equals'.

I wonder whether the difference between strings and numbers could be even more
obvious by changing the entry into query building. Right now we have:

Query luceneQuery = queryBuilder 
    .keyword()
    ...

Query luceneQuery = queryBuilder 
    .range()
    ...

We could have an additional level:

 Query luceneQuery = queryBuilder
     .string() 
     .keyword()
     ...
 
 Query luceneQuery = queryBuilder
     .numeric()
     .range()
     ...

Obviously not backwards compatible. Food for thought.

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150827/30e4bf85/attachment.bin