After implementing some basic query validation rules, I came across another problem/bordercase. The problems manifests itself for example in IterableBridgeTesst#testSearchNullNumericEntry. ATM, our default numeric bridges honor the indexNullAs option of @Field:

//...
	@Override
	public void set(String name, Object value, Document document, LuceneOptions luceneOptions) {
		if ( value == null ) {
			if ( luceneOptions.indexNullAs() != null ) {
				luceneOptions.addFieldToDocument( name, luceneOptions.indexNullAs(), document );
			}
		}
		else {
			applyToLuceneOptions( luceneOptions, name, (Number)value, document );
		}
	}
//...

As seen in the code, if the value to index is null and the indexNullAs flag is set, the string based null token is inserted, in all other cases the value is indexed as number. Metadata wise the field is considered numeric. If one tries now to write a term query against this numeric field, trying to find null values by searching for the null token, the validation routine will complain that a string query is targeting a numeric field (which is otherwise invalid to what we have discussed before). What do we do here?

• Should the validation also check for the null token and set not enforce a numeric query only against this field?
• Disallow string based null tokens for numeric fields?
  • If so, should we somehow introduce a numeric null token equivalent!?