Package org.apache.solr.update.processor

Class AddSchemaFieldsUpdateProcessorFactory

  • All Implemented Interfaces:
    UpdateRequestProcessorFactory.RunAlways, NamedListInitializedPlugin, SolrCoreAware
    public class AddSchemaFieldsUpdateProcessorFactory
extends UpdateRequestProcessorFactory
implements SolrCoreAware, UpdateRequestProcessorFactory.RunAlways

    This processor will dynamically add fields to the schema if an input document contains one or more fields that don't match any field or dynamic field in the schema.

    By default, this processor selects all fields that don't match a schema field or dynamic field. The "fieldName" and "fieldRegex" selectors may be specified to further restrict the selected fields, but the other selectors ("typeName", "typeClass", and "fieldNameMatchesSchemaField") may not be specified.

    This processor is configured to map from each field's values' class(es) to the schema field type that will be used when adding the new field to the schema. All new fields are then added to the schema in a single batch. If schema addition fails for any field, addition is re-attempted only for those that don’t match any schema field. This process is repeated, either until all new fields are successfully added, or until there are no new fields (presumably because the fields that were new when this processor started its work were subsequently added by a different update request, possibly on a different node).

    This processor takes as configuration a sequence of zero or more "typeMapping"-s from one or more "valueClass"-s, specified as either an <arr> of <str>, or multiple <str> with the same name, to an existing schema "fieldType".

    If more than one "valueClass" is specified in a "typeMapping", field values with any of the specified "valueClass"-s will be mapped to the specified target "fieldType". The "typeMapping"-s are attempted in the specified order; if a field value's class is not specified in a "valueClass", the next "typeMapping" is attempted. If no "typeMapping" succeeds, then either the "typeMapping" configured with <bool name="default">true</bool> is used, or if none is so configured, the lt;str name="defaultFieldType">...</str> is used.

    Zero or more "copyField" directives may be included with each "typeMapping", using a <lst>. The copy field source is automatically set to the new field name; "dest" must specify the destination field or dynamic field in a <str>; and "maxChars" may optionally be specified in an <int>.

    Example configuration: 

     <updateProcessor class="solr.AddSchemaFieldsUpdateProcessorFactory" name="add-schema-fields">
   <lst name="typeMapping">
     <str name="valueClass">java.lang.String</str>
     <str name="fieldType">text_general</str>
     <lst name="copyField">
       <str name="dest">*_str</str>
       <int name="maxChars">256</int>
     </lst>
     <!-- Use as default mapping instead of defaultFieldType -->
     <bool name="default">true</bool>
   </lst>
   <lst name="typeMapping">
     <str name="valueClass">java.lang.Boolean</str>
     <str name="fieldType">booleans</str>
   </lst>
   <lst name="typeMapping">
     <str name="valueClass">java.util.Date</str>
     <str name="fieldType">pdates</str>
   </lst>
   <lst name="typeMapping">
     <str name="valueClass">java.lang.Long</str>
     <str name="valueClass">java.lang.Integer</str>
     <str name="fieldType">plongs</str>
   </lst>
   <lst name="typeMapping">
     <str name="valueClass">java.lang.Number</str>
     <str name="fieldType">pdoubles</str>
   </lst>
 </updateProcessor>
    Since:
    4.4.0