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
pgppEwiea6Mom.pgp
Description: PGP signature
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
