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

Reply via email to