[hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

[Gunnar Morling]

2015-08-11 0:18 GMT+02:00 Sanne Grinovero <sanne at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev