Having a dedicated API to define index field types, or encodings, regardless of when and where that encoding is used, could help in several ways:

• Dynamic field APIs could re-use this encoding definition API, or require an encoding to be passed when defining a dynamic field; see HSEARCH-3273 Open
• We could make ValueBridge#bind cleaner by passing it interfaces from the encoding definition API instead of the field definition API (i.e. the ValueBridge would no longer be able to create an accessor)

Below is a concrete example; instead of having this:

@Override
public void bind(IndexSchemaElement indexSchemaElement,
		PojoModelProperty bridgedPojoModelProperty,
		SearchModel searchModel) {
	this.textFieldAccessor = indexSchemaElement
		.field( "fieldName" ).asString().createAccessor();
}

… we would probably have something like this:

@Override
public void bind(IndexModel indexModel,
		IndexSchemaElement indexSchemaElement,
		PojoModelProperty bridgedPojoModelProperty,
		SearchModel searchModel) {
	this.textFieldAccessor = indexSchemaElement.field( "fieldName" )
		.encoding( indexModel.encoding().asString() )
		.createAccessor();
}

Then when dynamic fields get introduced ( HSEARCH-3273 Open ), we can also reuse the encoding definition API, i.e.:

@Override
public void bind(IndexModel indexModel,
		IndexSchemaElement indexSchemaElement,
		PojoModelProperty bridgedPojoModelProperty,
		SearchModel searchModel) {
	this.dynamicTextFieldAccessor =
		indexSchemaElement.dynamicField().encoding( indexModel.encoding().asString() )
		// This would return a different type of accessor requiring a field name
		.createAccessor();

Related: HSEARCH-3217 Open . Maybe it should be closed as obsolete, maybe it is still relevant for the encoding definition API.