Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?
2015-08-11 0:18 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
> One possible workaround is to enforce the indexNullAs value to
match the
> underlying field type, at the
> moment it is always a string.
Interesting idea, but the user would need to provide which "value"
he's ok to give up, as he would need to pick a number to be treated as
NaN.
Since the indexNullAs parameter requires a string, would we expect
people to write a number in there?
+1 for that idea.
It'd work very well in the ES case where null tokens are also expected
to be of the correct type, e.g. the number -1 for a numeric field.
Also leaving ES aside, I find it troubling that setting indexNullAs()
transparently alters the type of a field of a numeric property from
IntField etc. to a string field.
> Another possibility is to model "null" as field not present in the lucene
> document, instead of a marker token.
Thanks! I've run some tests with this and have a patch working based
on this idea; I was sceptical initially because of scoring, but it
seems it's doable without needing to score all documents on this
negation. I'll send a PR soon; basically with this approach the
indexNullAs attribute will be ignored, but it's ok I think as this
solution is better and there's no drawback (nor needing any user
configuration).
Isn't that what's happening already atm.? If a value is null (and
indexNullAs() is *not* given), it will not be part of the index as per
my observations. But if it is null and indexNullAs() is given, that
token will be used. That seems like the right thing to do IMO. Esp. I
would not ignore indexNullAs() if given, apparently the user meant to
encode null in that case e.g. to use it in queries.
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev