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