Thanks, very helpful. I think I'm on the right track now, but when I do a post now and my UpdateRequestProcessor extension tries to add a field to a document, I get:
RequestHandlerBase org.apache.solr.common.SolrException: ERROR: [doc=1] Error adding field 'myField'='2234543' The call I'm making is SolrInputDocument.addField(field name, value). Is that trying to add a field to the schema.xml? The field (myField) is already defined in schema.xml. By calling SolrInputDocument.addField(), my goal is to add the field to the document and give it a value. On Tue, Jan 19, 2016 at 1:28 PM, Erick Erickson <erickerick...@gmail.com> wrote: > You _are_ using the mutating update processor. You have this: > > <updateRequestProcessorChain name="add-unknown-fields-to-the-schema"> > . > . > . > </updateRequestProcessorChain> > > and "add-unknown-field-to-the-schema" is in your update section here: > > <initParams path="/update/**"> > <lst name="defaults"> > <str name="update.chain">add-unknown-fields-to-the-schema</str> > </lst> > </initParams> > > As to what field is in the doc but not in the schema, the solr log > will probably help... > > Best, > Erick > > On Tue, Jan 19, 2016 at 10:19 AM, Bob Lawson <bwlawson...@gmail.com> > wrote: > > <?xml version="1.0" encoding="UTF-8" ?> > > <!-- > > Licensed to the Apache Software Foundation (ASF) under one or more > > contributor license agreements. See the NOTICE file distributed with > > this work for additional information regarding copyright ownership. > > The ASF licenses this file to You under the Apache License, Version 2.0 > > (the "License"); you may not use this file except in compliance with > > the License. You may obtain a copy of the License at > > > > http://www.apache.org/licenses/LICENSE-2.0 > > > > Unless required by applicable law or agreed to in writing, software > > distributed under the License is distributed on an "AS IS" BASIS, > > WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > > See the License for the specific language governing permissions and > > limitations under the License. > > --> > > > > <!-- > > For more details about configurations options that may appear in > > this file, see http://wiki.apache.org/solr/SolrConfigXml. > > --> > > <config> > > <!-- In all configuration below, a prefix of "solr." for class names > > is an alias that causes solr to search appropriate packages, > > including org.apache.solr.(search|update|request|core|analysis) > > > > You may also specify a fully qualified Java classname if you > > have your own custom plugins. > > --> > > > > <!-- Controls what version of Lucene various components of Solr > > adhere to. Generally, you want to use the latest version to > > get all bug fixes and improvements. It is highly recommended > > that you fully re-index after changing this setting as it can > > affect both how text is indexed and queried. > > --> > > <luceneMatchVersion>5.4.0</luceneMatchVersion> > > > > <!-- <lib/> directives can be used to instruct Solr to load any Jars > > identified and use them to resolve any "plugins" specified in > > your solrconfig.xml or schema.xml (ie: Analyzers, Request > > Handlers, etc...). > > > > All directories and paths are resolved relative to the > > instanceDir. > > > > Please note that <lib/> directives are processed in the order > > that they appear in your solrconfig.xml file, and are "stacked" > > on top of each other when building a ClassLoader - so if you have > > plugin jars with dependencies on other jars, the "lower level" > > dependency jars should be loaded first. > > > > If a "./lib" directory exists in your instanceDir, all files > > found in it are included as if you had used the following > > syntax... > > > > <lib dir="./lib" /> > > --> > > > > <!-- A 'dir' option by itself adds any files found in the directory > > to the classpath, this is useful for including all jars in a > > directory. > > > > When a 'regex' is specified in addition to a 'dir', only the > > files in that directory which completely match the regex > > (anchored on both ends) will be included. > > > > If a 'dir' option (with or without a regex) is used and nothing > > is found that matches, a warning will be logged. > > > > The examples below can be used to load some solr-contribs along > > with their external dependencies. > > --> > > <lib dir="${solr.install.dir:../../../..}/contrib/extraction/lib" > > regex=".*\.jar" /> > > <lib dir="${solr.install.dir:../../../..}/dist/" > > regex="solr-cell-\d.*\.jar" /> > > > > <lib dir="${solr.install.dir:../../../..}/contrib/clustering/lib/" > > regex=".*\.jar" /> > > <lib dir="${solr.install.dir:../../../..}/dist/" > > regex="solr-clustering-\d.*\.jar" /> > > > > <lib dir="${solr.install.dir:../../../..}/contrib/langid/lib/" > > regex=".*\.jar" /> > > <lib dir="${solr.install.dir:../../../..}/dist/" > > regex="solr-langid-\d.*\.jar" /> > > > > <lib dir="${solr.install.dir:../../../..}/contrib/velocity/lib" > > regex=".*\.jar" /> > > <lib dir="${solr.install.dir:../../../..}/dist/" > > regex="solr-velocity-\d.*\.jar" /> > > <!-- an exact 'path' can be used instead of a 'dir' to specify a > > specific jar file. This will cause a serious error to be logged > > if it can't be loaded. > > --> > > <!-- > > <lib path="../a-jar-that-does-not-exist.jar" /> > > --> > > > > <!-- Data Directory > > > > Used to specify an alternate directory to hold all index data > > other than the default ./data under the Solr home. If > > replication is in use, this should match the replication > > configuration. > > --> > > <dataDir>${solr.data.dir:}</dataDir> > > > > > > <!-- The DirectoryFactory to use for indexes. > > > > solr.StandardDirectoryFactory is filesystem > > based and tries to pick the best implementation for the current > > JVM and platform. solr.NRTCachingDirectoryFactory, the default, > > wraps solr.StandardDirectoryFactory and caches small files in > memory > > for better NRT performance. > > > > One can force a particular implementation via > > solr.MMapDirectoryFactory, > > solr.NIOFSDirectoryFactory, or solr.SimpleFSDirectoryFactory. > > > > solr.RAMDirectoryFactory is memory based, not > > persistent, and doesn't work with replication. > > --> > > <directoryFactory name="DirectoryFactory" > > > > class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}"/> > > > > <!-- The CodecFactory for defining the format of the inverted index. > > The default implementation is SchemaCodecFactory, which is the > > official Lucene > > index format, but hooks into the schema to provide per-field > > customization of > > the postings lists and per-document values in the fieldType > element > > (postingsFormat/docValuesFormat). Note that most of the > alternative > > implementations > > are experimental, so if you choose to customize the index format, > > it's a good > > idea to convert back to the official format e.g. via > > IndexWriter.addIndexes(IndexReader) > > before upgrading to a newer version to avoid unnecessary > reindexing. > > --> > > <codecFactory class="solr.SchemaCodecFactory"/> > > > > <!-- To disable dynamic schema REST APIs, use the following for > > <schemaFactory>: > > > > <schemaFactory class="ClassicIndexSchemaFactory"/> > > > > When ManagedIndexSchemaFactory is specified instead, Solr will > load > > the schema from > > the resource named in 'managedSchemaResourceName', rather than > from > > schema.xml. > > Note that the managed schema resource CANNOT be named schema.xml. > > If the managed > > schema does not exist, Solr will create it after reading > schema.xml, > > then rename > > 'schema.xml' to 'schema.xml.bak'. > > > > Do NOT hand edit the managed schema - external modifications will > be > > ignored and > > overwritten as a result of schema modification REST API calls. > > > > When ManagedIndexSchemaFactory is specified with mutable = true, > > schema > > modification REST API calls will be allowed; otherwise, error > > responses will be > > sent back for these requests. > > <schemaFactory class="ManagedIndexSchemaFactory"> > > <bool name="mutable">true</bool> > > <str name="managedSchemaResourceName">managed-schema</str> > > </schemaFactory> > > --> > > > > <!-- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Index Config - These settings control low-level behavior of > indexing > > Most example settings here show the default value, but are > commented > > out, to more easily see where customizations have been made. > > > > Note: This replaces <indexDefaults> and <mainIndex> from older > > versions > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> > > <indexConfig> > > <!-- maxFieldLength was removed in 4.0. To get similar behavior, > > include a > > LimitTokenCountFilterFactory in your fieldType definition. E.g. > > <filter class="solr.LimitTokenCountFilterFactory" > > maxTokenCount="10000"/> > > --> > > <!-- Maximum time to wait for a write lock (ms) for an IndexWriter. > > Default: 1000 --> > > <!-- <writeLockTimeout>1000</writeLockTimeout> --> > > > > <!-- Expert: Enabling compound file will use less files for the > index, > > using fewer file descriptors on the expense of performance > > decrease. > > Default in Lucene is "true". Default in Solr is "false" (since > > 3.6) --> > > <!-- <useCompoundFile>false</useCompoundFile> --> > > > > <!-- ramBufferSizeMB sets the amount of RAM that may be used by > Lucene > > indexing for buffering added documents and deletions before they > > are > > flushed to the Directory. > > maxBufferedDocs sets a limit on the number of documents buffered > > before flushing. > > If both ramBufferSizeMB and maxBufferedDocs is set, then > > Lucene will flush based on whichever limit is hit first. --> > > <!-- <ramBufferSizeMB>100</ramBufferSizeMB> --> > > <!-- <maxBufferedDocs>1000</maxBufferedDocs> --> > > > > <!-- Expert: Merge Policy > > The Merge Policy in Lucene controls how merging of segments is > > done. > > The default since Solr/Lucene 3.3 is TieredMergePolicy. > > The default since Lucene 2.3 was the LogByteSizeMergePolicy, > > Even older versions of Lucene used LogDocMergePolicy. > > --> > > <!-- > > <mergePolicy class="org.apache.lucene.index.TieredMergePolicy"> > > <int name="maxMergeAtOnce">10</int> > > <int name="segmentsPerTier">10</int> > > <double name="noCFSRatio">0.1</double> > > </mergePolicy> > > --> > > > > <!-- Merge Factor > > The merge factor controls how many segments will get merged at a > > time. > > For TieredMergePolicy, mergeFactor is a convenience parameter > which > > will set both MaxMergeAtOnce and SegmentsPerTier at once. > > For LogByteSizeMergePolicy, mergeFactor decides how many new > > segments > > will be allowed before they are merged into one. > > Default is 10 for both merge policies. > > --> > > <!-- > > <mergeFactor>10</mergeFactor> > > --> > > > > <!-- Expert: Merge Scheduler > > The Merge Scheduler in Lucene controls how merges are > > performed. The ConcurrentMergeScheduler (Lucene 2.3 default) > > can perform merges in the background using separate threads. > > The SerialMergeScheduler (Lucene 2.2 default) does not. > > --> > > <!-- > > <mergeScheduler > > class="org.apache.lucene.index.ConcurrentMergeScheduler"/> > > --> > > > > <!-- LockFactory > > > > This option specifies which Lucene LockFactory implementation > > to use. > > > > single = SingleInstanceLockFactory - suggested for a > > read-only index or when there is no possibility of > > another process trying to modify the index. > > native = NativeFSLockFactory - uses OS native file locking. > > Do not use when multiple solr webapps in the same > > JVM are attempting to share a single index. > > simple = SimpleFSLockFactory - uses a plain file for locking > > > > Defaults: 'native' is default for Solr3.6 and later, otherwise > > 'simple' is the default > > > > More details on the nuances of each LockFactory... > > http://wiki.apache.org/lucene-java/AvailableLockFactories > > --> > > <lockType>${solr.lock.type:native}</lockType> > > > > <!-- Commit Deletion Policy > > Custom deletion policies can be specified here. The class must > > implement org.apache.lucene.index.IndexDeletionPolicy. > > > > The default Solr IndexDeletionPolicy implementation supports > > deleting index commit points on number of commits, age of > > commit point and optimized status. > > > > The latest commit point should always be preserved regardless > > of the criteria. > > --> > > <!-- > > <deletionPolicy class="solr.SolrDeletionPolicy"> > > --> > > <!-- The number of commit points to be kept --> > > <!-- <str name="maxCommitsToKeep">1</str> --> > > <!-- The number of optimized commit points to be kept --> > > <!-- <str name="maxOptimizedCommitsToKeep">0</str> --> > > <!-- > > Delete all commit points once they have reached the given age. > > Supports DateMathParser syntax e.g. > > --> > > <!-- > > <str name="maxCommitAge">30MINUTES</str> > > <str name="maxCommitAge">1DAY</str> > > --> > > <!-- > > </deletionPolicy> > > --> > > > > <!-- Lucene Infostream > > > > To aid in advanced debugging, Lucene provides an "InfoStream" > > of detailed information when indexing. > > > > Setting The value to true will instruct the underlying Lucene > > IndexWriter to write its debugging info the specified file > > --> > > <!-- <infoStream file="INFOSTREAM.txt">false</infoStream> --> > > </indexConfig> > > > > > > <!-- JMX > > > > This example enables JMX if and only if an existing MBeanServer > > is found, use this if you want to configure JMX through JVM > > parameters. Remove this to disable exposing Solr configuration > > and statistics to JMX. > > > > For more details see http://wiki.apache.org/solr/SolrJmx > > --> > > <jmx /> > > <!-- If you want to connect to a particular server, specify the > > agentId > > --> > > <!-- <jmx agentId="myAgent" /> --> > > <!-- If you want to start a new MBeanServer, specify the serviceUrl --> > > <!-- <jmx > serviceUrl="service:jmx:rmi:///jndi/rmi://localhost:9999/solr"/> > > --> > > > > <!-- The default high-performance update handler --> > > <updateHandler class="solr.DirectUpdateHandler2"> > > > > <!-- Enables a transaction log, used for real-time get, durability, > and > > and solr cloud replica recovery. The log can grow as big as > > uncommitted changes to the index, so use of a hard autoCommit > > is recommended (see below). > > "dir" - the target directory for transaction logs, defaults to > the > > solr data directory. > > "numVersionBuckets" - sets the number of buckets used to keep > > track of max version values when checking for re-ordered > > updates; increase this value to reduce the cost of > > synchronizing access to version buckets during > high-volume > > indexing, this requires 8 bytes (long) * > numVersionBuckets > > of heap space per Solr core. > > --> > > <updateLog> > > <str name="dir">${solr.ulog.dir:}</str> > > <int > > name="numVersionBuckets">${solr.ulog.numVersionBuckets:65536}</int> > > </updateLog> > > > > <!-- AutoCommit > > > > Perform a hard commit automatically under certain conditions. > > Instead of enabling autoCommit, consider using "commitWithin" > > when adding documents. > > > > http://wiki.apache.org/solr/UpdateXmlMessages > > > > maxDocs - Maximum number of documents to add since the last > > commit before automatically triggering a new commit. > > > > maxTime - Maximum amount of time in ms that is allowed to pass > > since a document was added before automatically > > triggering a new commit. > > openSearcher - if false, the commit causes recent index changes > > to be flushed to stable storage, but does not cause a new > > searcher to be opened to make those changes visible. > > > > If the updateLog is enabled, then it's highly recommended to > > have some sort of hard autoCommit to limit the log size. > > --> > > <autoCommit> > > <maxTime>${solr.autoCommit.maxTime:15000}</maxTime> > > <openSearcher>false</openSearcher> > > </autoCommit> > > > > <!-- softAutoCommit is like autoCommit except it causes a > > 'soft' commit which only ensures that changes are visible > > but does not ensure that data is synced to disk. This is > > faster and more near-realtime friendly than a hard commit. > > --> > > > > <autoSoftCommit> > > <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime> > > </autoSoftCommit> > > > > <!-- Update Related Event Listeners > > > > Various IndexWriter related events can trigger Listeners to > > take actions. > > > > postCommit - fired after every commit or optimize command > > postOptimize - fired after every optimize command > > --> > > <!-- The RunExecutableListener executes an external command from a > > hook such as postCommit or postOptimize. > > > > exe - the name of the executable to run > > dir - dir to use as the current working directory. (default=".") > > wait - the calling thread waits until the executable returns. > > (default="true") > > args - the arguments to pass to the program. (default is none) > > env - environment variables to set. (default is none) > > --> > > <!-- This example shows how RunExecutableListener could be used > > with the script based replication... > > http://wiki.apache.org/solr/CollectionDistribution > > --> > > <!-- > > <listener event="postCommit" class="solr.RunExecutableListener"> > > <str name="exe">solr/bin/snapshooter</str> > > <str name="dir">.</str> > > <bool name="wait">true</bool> > > <arr name="args"> <str>arg1</str> <str>arg2</str> </arr> > > <arr name="env"> <str>MYVAR=val1</str> </arr> > > </listener> > > --> > > > > </updateHandler> > > > > <!-- IndexReaderFactory > > > > Use the following format to specify a custom IndexReaderFactory, > > which allows for alternate IndexReader implementations. > > > > ** Experimental Feature ** > > > > Please note - Using a custom IndexReaderFactory may prevent > > certain other features from working. The API to > > IndexReaderFactory may change without warning or may even be > > removed from future releases if the problems cannot be > > resolved. > > > > > > ** Features that may not work with custom IndexReaderFactory ** > > > > The ReplicationHandler assumes a disk-resident index. Using a > > custom IndexReader implementation may cause incompatibility > > with ReplicationHandler and may cause replication to not work > > correctly. See SOLR-1366 for details. > > > > --> > > <!-- > > <indexReaderFactory name="IndexReaderFactory" class="package.class"> > > <str name="someArg">Some Value</str> > > </indexReaderFactory > > > --> > > > > <!-- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Query section - these settings control query time things like > caches > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> > > <query> > > <!-- Max Boolean Clauses > > > > Maximum number of clauses in each BooleanQuery, an exception > > is thrown if exceeded. > > > > ** WARNING ** > > > > This option actually modifies a global Lucene property that > > will affect all SolrCores. If multiple solrconfig.xml files > > disagree on this property, the value at any given moment will > > be based on the last SolrCore to be initialized. > > > > --> > > <maxBooleanClauses>1024</maxBooleanClauses> > > > > > > <!-- Solr Internal Query Caches > > > > There are two implementations of cache available for Solr, > > LRUCache, based on a synchronized LinkedHashMap, and > > FastLRUCache, based on a ConcurrentHashMap. > > > > FastLRUCache has faster gets and slower puts in single > > threaded operation and thus is generally faster than LRUCache > > when the hit ratio of the cache is high (> 75%), and may be > > faster under other scenarios on multi-cpu systems. > > --> > > > > <!-- Filter Cache > > > > Cache used by SolrIndexSearcher for filters (DocSets), > > unordered sets of *all* documents that match a query. When a > > new searcher is opened, its caches may be prepopulated or > > "autowarmed" using data from caches in the old searcher. > > autowarmCount is the number of items to prepopulate. For > > LRUCache, the autowarmed items will be the most recently > > accessed items. > > > > Parameters: > > class - the SolrCache implementation LRUCache or > > (LRUCache or FastLRUCache) > > size - the maximum number of entries in the cache > > initialSize - the initial capacity (number of entries) of > > the cache. (see java.util.HashMap) > > autowarmCount - the number of entries to prepopulate from > > and old cache. > > --> > > <filterCache class="solr.FastLRUCache" > > size="512" > > initialSize="512" > > autowarmCount="0"/> > > > > <!-- Query Result Cache > > > > Caches results of searches - ordered lists of document ids > > (DocList) based on a query, a sort, and the range of documents > > requested. > > Additional supported parameter by LRUCache: > > maxRamMB - the maximum amount of RAM (in MB) that this cache > is > > allowed > > to occupy > > --> > > <queryResultCache class="solr.LRUCache" > > size="512" > > initialSize="512" > > autowarmCount="0"/> > > > > <!-- Document Cache > > > > Caches Lucene Document objects (the stored fields for each > > document). Since Lucene internal document ids are transient, > > this cache will not be autowarmed. > > --> > > <documentCache class="solr.LRUCache" > > size="512" > > initialSize="512" > > autowarmCount="0"/> > > > > <!-- custom cache currently used by block join --> > > <cache name="perSegFilter" > > class="solr.search.LRUCache" > > size="10" > > initialSize="0" > > autowarmCount="10" > > regenerator="solr.NoOpRegenerator" /> > > > > <!-- Field Value Cache > > > > Cache used to hold field values that are quickly accessible > > by document id. The fieldValueCache is created by default > > even if not configured here. > > --> > > <!-- > > <fieldValueCache class="solr.FastLRUCache" > > size="512" > > autowarmCount="128" > > showItems="32" /> > > --> > > > > <!-- Custom Cache > > > > Example of a generic cache. These caches may be accessed by > > name through SolrIndexSearcher.getCache(),cacheLookup(), and > > cacheInsert(). The purpose is to enable easy caching of > > user/application level data. The regenerator argument should > > be specified as an implementation of solr.CacheRegenerator > > if autowarming is desired. > > --> > > <!-- > > <cache name="myUserCache" > > class="solr.LRUCache" > > size="4096" > > initialSize="1024" > > autowarmCount="1024" > > regenerator="com.mycompany.MyRegenerator" > > /> > > --> > > > > > > <!-- Lazy Field Loading > > > > If true, stored fields that are not requested will be loaded > > lazily. This can result in a significant speed improvement > > if the usual case is to not load all stored fields, > > especially if the skipped fields are large compressed text > > fields. > > --> > > <enableLazyFieldLoading>true</enableLazyFieldLoading> > > > > <!-- Use Filter For Sorted Query > > > > A possible optimization that attempts to use a filter to > > satisfy a search. If the requested sort does not include > > score, then the filterCache will be checked for a filter > > matching the query. If found, the filter will be used as the > > source of document ids, and then the sort will be applied to > > that. > > > > For most situations, this will not be useful unless you > > frequently get the same search repeatedly with different sort > > options, and none of them ever use "score" > > --> > > <!-- > > <useFilterForSortedQuery>true</useFilterForSortedQuery> > > --> > > > > <!-- Result Window Size > > > > An optimization for use with the queryResultCache. When a > search > > is requested, a superset of the requested number of document ids > > are collected. For example, if a search for a particular query > > requests matching documents 10 through 19, and queryWindowSize > is > > 50, > > then documents 0 through 49 will be collected and cached. Any > > further > > requests in that range can be satisfied via the cache. > > --> > > <queryResultWindowSize>20</queryResultWindowSize> > > > > <!-- Maximum number of documents to cache for any entry in the > > queryResultCache. > > --> > > <queryResultMaxDocsCached>200</queryResultMaxDocsCached> > > > > <!-- Query Related Event Listeners > > > > Various IndexSearcher related events can trigger Listeners to > > take actions. > > > > newSearcher - fired whenever a new searcher is being prepared > > and there is a current searcher handling requests (aka > > registered). It can be used to prime certain caches to > > prevent long request times for certain requests. > > > > firstSearcher - fired whenever a new searcher is being > > prepared but there is no current registered searcher to handle > > requests or to gain autowarming data from. > > > > > > --> > > <!-- QuerySenderListener takes an array of NamedList and executes a > > local query request for each NamedList in sequence. > > --> > > <listener event="newSearcher" class="solr.QuerySenderListener"> > > <arr name="queries"> > > <!-- > > <lst><str name="q">solr</str><str name="sort">price > > asc</str></lst> > > <lst><str name="q">rocks</str><str name="sort">weight > > asc</str></lst> > > --> > > </arr> > > </listener> > > <listener event="firstSearcher" class="solr.QuerySenderListener"> > > <arr name="queries"> > > <!-- > > <lst> > > <str name="q">static firstSearcher warming in > solrconfig.xml</str> > > </lst> > > --> > > </arr> > > </listener> > > > > <!-- Use Cold Searcher > > > > If a search request comes in and there is no current > > registered searcher, then immediately register the still > > warming searcher and use it. If "false" then all requests > > will block until the first searcher is done warming. > > --> > > <useColdSearcher>false</useColdSearcher> > > > > <!-- Max Warming Searchers > > > > Maximum number of searchers that may be warming in the > > background concurrently. An error is returned if this limit > > is exceeded. > > > > Recommend values of 1-2 for read-only slaves, higher for > > masters w/o cache warming. > > --> > > <maxWarmingSearchers>2</maxWarmingSearchers> > > > > </query> > > > > > > <!-- Request Dispatcher > > > > This section contains instructions for how the SolrDispatchFilter > > should behave when processing requests for this SolrCore. > > > > handleSelect is a legacy option that affects the behavior of > requests > > such as /select?qt=XXX > > > > handleSelect="true" will cause the SolrDispatchFilter to process > > the request and dispatch the query to a handler specified by the > > "qt" param, assuming "/select" isn't already registered. > > > > handleSelect="false" will cause the SolrDispatchFilter to > > ignore "/select" requests, resulting in a 404 unless a handler > > is explicitly registered with the name "/select" > > > > handleSelect="true" is not recommended for new users, but is the > > default > > for backwards compatibility > > --> > > <requestDispatcher handleSelect="false" > > > <!-- Request Parsing > > > > These settings indicate how Solr Requests may be parsed, and > > what restrictions may be placed on the ContentStreams from > > those requests > > > > enableRemoteStreaming - enables use of the stream.file > > and stream.url parameters for specifying remote streams. > > > > multipartUploadLimitInKB - specifies the max size (in KiB) of > > Multipart File Uploads that Solr will allow in a Request. > > > > formdataUploadLimitInKB - specifies the max size (in KiB) of > > form data (application/x-www-form-urlencoded) sent via > > POST. You can use POST to pass request parameters not > > fitting into the URL. > > > > addHttpRequestToContext - if set to true, it will instruct > > the requestParsers to include the original HttpServletRequest > > object in the context map of the SolrQueryRequest under the > > key "httpRequest". It will not be used by any of the existing > > Solr components, but may be useful when developing custom > > plugins. > > > > *** WARNING *** > > The settings below authorize Solr to fetch remote files, You > > should make sure your system has some authentication before > > using enableRemoteStreaming="true" > > > > --> > > <requestParsers enableRemoteStreaming="true" > > multipartUploadLimitInKB="2048000" > > formdataUploadLimitInKB="2048" > > addHttpRequestToContext="false"/> > > > > <!-- HTTP Caching > > > > Set HTTP caching related parameters (for proxy caches and > clients). > > > > The options below instruct Solr not to output any HTTP Caching > > related headers > > --> > > <httpCaching never304="true" /> > > <!-- If you include a <cacheControl> directive, it will be used to > > generate a Cache-Control header (as well as an Expires header > > if the value contains "max-age=") > > > > By default, no Cache-Control header is generated. > > > > You can use the <cacheControl> option even if you have set > > never304="true" > > --> > > <!-- > > <httpCaching never304="true" > > > <cacheControl>max-age=30, public</cacheControl> > > </httpCaching> > > --> > > <!-- To enable Solr to respond with automatically generated HTTP > > Caching headers, and to response to Cache Validation requests > > correctly, set the value of never304="false" > > > > This will cause Solr to generate Last-Modified and ETag > > headers based on the properties of the Index. > > > > The following options can also be specified to affect the > > values of these headers... > > > > lastModFrom - the default value is "openTime" which means the > > Last-Modified value (and validation against If-Modified-Since > > requests) will all be relative to when the current Searcher > > was opened. You can change it to lastModFrom="dirLastMod" if > > you want the value to exactly correspond to when the physical > > index was last modified. > > > > etagSeed="..." is an option you can change to force the ETag > > header (and validation against If-None-Match requests) to be > > different even if the index has not changed (ie: when making > > significant changes to your config file) > > > > (lastModifiedFrom and etagSeed are both ignored if you use > > the never304="true" option) > > --> > > <!-- > > <httpCaching lastModifiedFrom="openTime" > > etagSeed="Solr"> > > <cacheControl>max-age=30, public</cacheControl> > > </httpCaching> > > --> > > </requestDispatcher> > > > > <!-- Request Handlers > > > > http://wiki.apache.org/solr/SolrRequestHandler > > > > Incoming queries will be dispatched to a specific handler by name > > based on the path specified in the request. > > > > Legacy behavior: If the request path uses "/select" but no Request > > Handler has that name, and if handleSelect="true" has been > specified > > in > > the requestDispatcher, then the Request Handler is dispatched > based > > on > > the qt parameter. Handlers without a leading '/' are accessed > this > > way > > like so: http://host/app/[core/]select?qt=name If no qt is > > given, then the requestHandler that declares default="true" will > be > > used or the one named "standard". > > > > If a Request Handler is declared with startup="lazy", then it will > > not be initialized until the first request that uses it. > > > > --> > > <!-- SearchHandler > > > > http://wiki.apache.org/solr/SearchHandler > > > > For processing Search Queries, the primary Request Handler > > provided with Solr is "SearchHandler" It delegates to a sequent > > of SearchComponents (see below) and supports distributed > > queries across multiple shards > > --> > > <requestHandler name="/select" class="solr.SearchHandler"> > > <!-- default values for query parameters can be specified, these > > will be overridden by parameters in the request > > --> > > <lst name="defaults"> > > <str name="echoParams">explicit</str> > > <int name="rows">10</int> > > <!-- <str name="df">text</str> --> > > </lst> > > <!-- In addition to defaults, "appends" params can be specified > > to identify values which should be appended to the list of > > multi-val params from the query (or the existing "defaults"). > > --> > > <!-- In this example, the param "fq=instock:true" would be appended > to > > any query time fq params the user may specify, as a mechanism > for > > partitioning the index, independent of any user selected > filtering > > that may also be desired (perhaps as a result of faceted > > searching). > > > > NOTE: there is *absolutely* nothing a client can do to prevent > > these > > "appends" values from being used, so don't use this mechanism > > unless you are sure you always want it. > > --> > > <!-- > > <lst name="appends"> > > <str name="fq">inStock:true</str> > > </lst> > > --> > > <!-- "invariants" are a way of letting the Solr maintainer lock down > > the options available to Solr clients. Any params values > > specified here are used regardless of what values may be > specified > > in either the query, the "defaults", or the "appends" params. > > > > In this example, the facet.field and facet.query params would > > be fixed, limiting the facets clients can use. Faceting is > > not turned on by default - but if the client does specify > > facet=true in the request, these are the only facets they > > will be able to see counts for; regardless of what other > > facet.field or facet.query params they may specify. > > > > NOTE: there is *absolutely* nothing a client can do to prevent > > these > > "invariants" values from being used, so don't use this mechanism > > unless you are sure you always want it. > > --> > > <!-- > > <lst name="invariants"> > > <str name="facet.field">cat</str> > > <str name="facet.field">manu_exact</str> > > <str name="facet.query">price:[* TO 500]</str> > > <str name="facet.query">price:[500 TO *]</str> > > </lst> > > --> > > <!-- If the default list of SearchComponents is not desired, that > > list can either be overridden completely, or components can be > > prepended or appended to the default list. (see below) > > --> > > <!-- > > <arr name="components"> > > <str>nameOfCustomComponent1</str> > > <str>nameOfCustomComponent2</str> > > </arr> > > --> > > </requestHandler> > > > > <!-- A request handler that returns indented JSON by default --> > > <requestHandler name="/query" class="solr.SearchHandler"> > > <lst name="defaults"> > > <str name="echoParams">explicit</str> > > <str name="wt">json</str> > > <str name="indent">true</str> > > </lst> > > </requestHandler> > > > > > > <requestHandler name="/browse" class="solr.SearchHandler" > > useParams="query,facets,velocity,browse"> > > <lst name="defaults"> > > <str name="echoParams">explicit</str> > > </lst> > > </requestHandler> > > > > > > <initParams > > path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse"> > > <lst name="defaults"> > > <str name="df">_text_</str> > > </lst> > > </initParams> > > > > <initParams path="/update/**"> > > <lst name="defaults"> > > <str name="update.chain">add-unknown-fields-to-the-schema</str> > > </lst> > > </initParams> > > > > <!-- Solr Cell Update Request Handler > > > > http://wiki.apache.org/solr/ExtractingRequestHandler > > > > --> > > <requestHandler name="/update/extract" > > startup="lazy" > > class="solr.extraction.ExtractingRequestHandler" > > > <lst name="defaults"> > > <str name="lowernames">true</str> > > <str name="fmap.meta">ignored_</str> > > <str name="fmap.content">_text_</str> > > </lst> > > </requestHandler> > > > > <!-- > > The export request handler is used to export full sorted result sets. > > Do not change these defaults. > > --> > > > > <requestHandler name="/export" class="solr.SearchHandler"> > > <lst name="invariants"> > > <str name="rq">{!xport}</str> > > <str name="wt">xsort</str> > > <str name="distrib">false</str> > > </lst> > > > > <arr name="components"> > > <str>query</str> > > </arr> > > </requestHandler> > > > > > > <!-- > > > > Uncomment for distributed Stream processing. > > > > SECURTIY WARNING: This feature uses Java Serialization for RPC (Remote > > Procedure Calls) to send executable > > Java Objects to Worker nodes. > > > > Solr also currently has apache commons-collections in > > it's classpath. > > > > This makes Solr vulnerable to this security exploit: > > > > > https://issues.apache.org/jira/browse/COLLECTIONS-580. > > > > > > <requestHandler name="/stream" class="solr.StreamHandler"> > > <lst name="invariants"> > > <str name="wt">json</str> > > <str name="distrib">false</str> > > </lst> > > </requestHandler> > > > > --> > > > > > > > > <!-- Field Analysis Request Handler > > > > RequestHandler that provides much the same functionality as > > analysis.jsp. Provides the ability to specify multiple field > > types and field names in the same request and outputs > > index-time and query-time analysis for each of them. > > > > Request parameters are: > > analysis.fieldname - field name whose analyzers are to be used > > > > analysis.fieldtype - field type whose analyzers are to be used > > analysis.fieldvalue - text for index-time analysis > > q (or analysis.q) - text for query time analysis > > analysis.showmatch (true|false) - When set to true and when > > query analysis is performed, the produced tokens of the > > field value analysis will be marked as "matched" for every > > token that is produces by the query analysis > > --> > > <requestHandler name="/analysis/field" > > startup="lazy" > > class="solr.FieldAnalysisRequestHandler" /> > > > > > > <!-- Document Analysis Handler > > > > http://wiki.apache.org/solr/AnalysisRequestHandler > > > > An analysis handler that provides a breakdown of the analysis > > process of provided documents. This handler expects a (single) > > content stream with the following format: > > > > <docs> > > <doc> > > <field name="id">1</field> > > <field name="name">The Name</field> > > <field name="text">The Text Value</field> > > </doc> > > <doc>...</doc> > > <doc>...</doc> > > ... > > </docs> > > > > Note: Each document must contain a field which serves as the > > unique key. This key is used in the returned response to associate > > an analysis breakdown to the analyzed document. > > > > Like the FieldAnalysisRequestHandler, this handler also supports > > query analysis by sending either an "analysis.query" or "q" > > request parameter that holds the query text to be analyzed. It > > also supports the "analysis.showmatch" parameter which when set to > > true, all field tokens that match the query tokens will be marked > > as a "match". > > --> > > <requestHandler name="/analysis/document" > > class="solr.DocumentAnalysisRequestHandler" > > startup="lazy" /> > > > > <!-- Echo the request contents back to the client --> > > <requestHandler name="/debug/dump" class="solr.DumpRequestHandler" > > > <lst name="defaults"> > > <str name="echoParams">explicit</str> > > <str name="echoHandler">true</str> > > </lst> > > </requestHandler> > > > > <searchComponent name="query" > > class="com.mydom.solrBob.plugin.BobQueryComponent" /> > > > > <!-- Search Components > > > > Search components are registered to SolrCore and used by > > instances of SearchHandler (which can access them by name) > > > > By default, the following components are available: > > > > <searchComponent name="query" class="solr.QueryComponent" /> > > <searchComponent name="facet" class="solr.FacetComponent" /> > > <searchComponent name="mlt" > class="solr.MoreLikeThisComponent" > > /> > > <searchComponent name="highlight" class="solr.HighlightComponent" > /> > > <searchComponent name="stats" class="solr.StatsComponent" /> > > <searchComponent name="debug" class="solr.DebugComponent" /> > > > > Default configuration in a requestHandler would look like: > > > > <arr name="components"> > > <str>query</str> > > <str>facet</str> > > <str>mlt</str> > > <str>highlight</str> > > <str>stats</str> > > <str>debug</str> > > </arr> > > > > If you register a searchComponent to one of the standard names, > > that will be used instead of the default. > > > > To insert components before or after the 'standard' components, > use: > > > > <arr name="first-components"> > > <str>myFirstComponentName</str> > > </arr> > > > > <arr name="last-components"> > > <str>myLastComponentName</str> > > </arr> > > > > NOTE: The component registered with the name "debug" will > > always be executed after the "last-components" > > > > --> > > > > <!-- Spell Check > > > > The spell check component can return a list of alternative > spelling > > suggestions. > > > > http://wiki.apache.org/solr/SpellCheckComponent > > --> > > <searchComponent name="spellcheck" class="solr.SpellCheckComponent"> > > > > <str name="queryAnalyzerFieldType">text_general</str> > > > > <!-- Multiple "Spell Checkers" can be declared and used by this > > component > > --> > > > > <!-- a spellchecker built from a field of the main index --> > > <lst name="spellchecker"> > > <str name="name">default</str> > > <str name="field">text</str> > > <str name="classname">solr.DirectSolrSpellChecker</str> > > <!-- the spellcheck distance measure used, the default is the > > internal levenshtein --> > > <str name="distanceMeasure">internal</str> > > <!-- minimum accuracy needed to be considered a valid spellcheck > > suggestion --> > > <float name="accuracy">0.5</float> > > <!-- the maximum #edits we consider when enumerating terms: can be > 1 > > or 2 --> > > <int name="maxEdits">2</int> > > <!-- the minimum shared prefix when enumerating terms --> > > <int name="minPrefix">1</int> > > <!-- maximum number of inspections per result. --> > > <int name="maxInspections">5</int> > > <!-- minimum length of a query term to be considered for correction > > --> > > <int name="minQueryLength">4</int> > > <!-- maximum threshold of documents a query term can appear to be > > considered for correction --> > > <float name="maxQueryFrequency">0.01</float> > > <!-- uncomment this to require suggestions to occur in 1% of the > > documents > > <float name="thresholdTokenFrequency">.01</float> > > --> > > </lst> > > > > <!-- a spellchecker that can break or combine words. See "/spell" > > handler below for usage --> > > <lst name="spellchecker"> > > <str name="name">wordbreak</str> > > <str name="classname">solr.WordBreakSolrSpellChecker</str> > > <str name="field">name</str> > > <str name="combineWords">true</str> > > <str name="breakWords">true</str> > > <int name="maxChanges">10</int> > > </lst> > > > > <!-- a spellchecker that uses a different distance measure --> > > <!-- > > <lst name="spellchecker"> > > <str name="name">jarowinkler</str> > > <str name="field">spell</str> > > <str name="classname">solr.DirectSolrSpellChecker</str> > > <str name="distanceMeasure"> > > org.apache.lucene.search.spell.JaroWinklerDistance > > </str> > > </lst> > > --> > > > > <!-- a spellchecker that use an alternate comparator > > > > comparatorClass be one of: > > 1. score (default) > > 2. freq (Frequency first, then score) > > 3. A fully qualified class name > > --> > > <!-- > > <lst name="spellchecker"> > > <str name="name">freq</str> > > <str name="field">lowerfilt</str> > > <str name="classname">solr.DirectSolrSpellChecker</str> > > <str name="comparatorClass">freq</str> > > --> > > > > <!-- A spellchecker that reads the list of words from a file --> > > <!-- > > <lst name="spellchecker"> > > <str name="classname">solr.FileBasedSpellChecker</str> > > <str name="name">file</str> > > <str name="sourceLocation">spellings.txt</str> > > <str name="characterEncoding">UTF-8</str> > > <str name="spellcheckIndexDir">spellcheckerFile</str> > > </lst> > > --> > > </searchComponent> > > > > <!-- A request handler for demonstrating the spellcheck component. > > > > NOTE: This is purely as an example. The whole purpose of the > > SpellCheckComponent is to hook it into the request handler that > > handles your normal user queries so that a separate request is > > not needed to get suggestions. > > > > IN OTHER WORDS, THERE IS REALLY GOOD CHANCE THE SETUP BELOW IS > > NOT WHAT YOU WANT FOR YOUR PRODUCTION SYSTEM! > > > > See http://wiki.apache.org/solr/SpellCheckComponent for details > > on the request parameters. > > --> > > <requestHandler name="/spell" class="solr.SearchHandler" > startup="lazy"> > > <lst name="defaults"> > > <!-- Solr will use suggestions from both the 'default' spellchecker > > and from the 'wordbreak' spellchecker and combine them. > > collations (re-written queries) can include a combination of > > corrections from both spellcheckers --> > > <str name="spellcheck.dictionary">default</str> > > <str name="spellcheck.dictionary">wordbreak</str> > > <str name="spellcheck">on</str> > > <str name="spellcheck.extendedResults">true</str> > > <str name="spellcheck.count">10</str> > > <str name="spellcheck.alternativeTermCount">5</str> > > <str name="spellcheck.maxResultsForSuggest">5</str> > > <str name="spellcheck.collate">true</str> > > <str name="spellcheck.collateExtendedResults">true</str> > > <str name="spellcheck.maxCollationTries">10</str> > > <str name="spellcheck.maxCollations">5</str> > > </lst> > > <arr name="last-components"> > > <str>spellcheck</str> > > </arr> > > </requestHandler> > > > > <!-- Term Vector Component > > > > http://wiki.apache.org/solr/TermVectorComponent > > --> > > <searchComponent name="tvComponent" class="solr.TermVectorComponent"/> > > > > <!-- A request handler for demonstrating the term vector component > > > > This is purely as an example. > > > > In reality you will likely want to add the component to your > > already specified request handlers. > > --> > > <requestHandler name="/tvrh" class="solr.SearchHandler" startup="lazy"> > > <lst name="defaults"> > > <bool name="tv">true</bool> > > </lst> > > <arr name="last-components"> > > <str>tvComponent</str> > > </arr> > > </requestHandler> > > > > <!-- Clustering Component. (Omitted here. See the default Solr example > > for a typical configuration.) --> > > > > <!-- Terms Component > > > > http://wiki.apache.org/solr/TermsComponent > > > > A component to return terms and document frequency of those > > terms > > --> > > <searchComponent name="terms" class="solr.TermsComponent"/> > > > > <!-- A request handler for demonstrating the terms component --> > > <requestHandler name="/terms" class="solr.SearchHandler" > startup="lazy"> > > <lst name="defaults"> > > <bool name="terms">true</bool> > > <bool name="distrib">false</bool> > > </lst> > > <arr name="components"> > > <str>terms</str> > > </arr> > > </requestHandler> > > > > > > <!-- Query Elevation Component > > > > http://wiki.apache.org/solr/QueryElevationComponent > > > > a search component that enables you to configure the top > > results for a given query regardless of the normal lucene > > scoring. > > --> > > <searchComponent name="elevator" class="solr.QueryElevationComponent" > > > <!-- pick a fieldType to analyze queries --> > > <str name="queryFieldType">string</str> > > <str name="config-file">elevate.xml</str> > > </searchComponent> > > > > <!-- A request handler for demonstrating the elevator component --> > > <requestHandler name="/elevate" class="solr.SearchHandler" > startup="lazy"> > > <lst name="defaults"> > > <str name="echoParams">explicit</str> > > </lst> > > <arr name="last-components"> > > <str>elevator</str> > > </arr> > > </requestHandler> > > > > <!-- Highlighting Component > > > > http://wiki.apache.org/solr/HighlightingParameters > > --> > > <searchComponent class="solr.HighlightComponent" name="highlight"> > > <highlighting> > > <!-- Configure the standard fragmenter --> > > <!-- This could most likely be commented out in the "default" case > --> > > <fragmenter name="gap" > > default="true" > > class="solr.highlight.GapFragmenter"> > > <lst name="defaults"> > > <int name="hl.fragsize">100</int> > > </lst> > > </fragmenter> > > > > <!-- A regular-expression-based fragmenter > > (for sentence extraction) > > --> > > <fragmenter name="regex" > > class="solr.highlight.RegexFragmenter"> > > <lst name="defaults"> > > <!-- slightly smaller fragsizes work better because of slop --> > > <int name="hl.fragsize">70</int> > > <!-- allow 50% slop on fragment sizes --> > > <float name="hl.regex.slop">0.5</float> > > <!-- a basic sentence pattern --> > > <str name="hl.regex.pattern">[-\w > ,/\n\"']{20,200}</str> > > </lst> > > </fragmenter> > > > > <!-- Configure the standard formatter --> > > <formatter name="html" > > default="true" > > class="solr.highlight.HtmlFormatter"> > > <lst name="defaults"> > > <str name="hl.simple.pre"><![CDATA[<em>]]></str> > > <str name="hl.simple.post"><![CDATA[</em>]]></str> > > </lst> > > </formatter> > > > > <!-- Configure the standard encoder --> > > <encoder name="html" > > class="solr.highlight.HtmlEncoder" /> > > > > <!-- Configure the standard fragListBuilder --> > > <fragListBuilder name="simple" > > class="solr.highlight.SimpleFragListBuilder"/> > > > > <!-- Configure the single fragListBuilder --> > > <fragListBuilder name="single" > > class="solr.highlight.SingleFragListBuilder"/> > > > > <!-- Configure the weighted fragListBuilder --> > > <fragListBuilder name="weighted" > > default="true" > > class="solr.highlight.WeightedFragListBuilder"/> > > > > <!-- default tag FragmentsBuilder --> > > <fragmentsBuilder name="default" > > default="true" > > > class="solr.highlight.ScoreOrderFragmentsBuilder"> > > <!-- > > <lst name="defaults"> > > <str name="hl.multiValuedSeparatorChar">/</str> > > </lst> > > --> > > </fragmentsBuilder> > > > > <!-- multi-colored tag FragmentsBuilder --> > > <fragmentsBuilder name="colored" > > > class="solr.highlight.ScoreOrderFragmentsBuilder"> > > <lst name="defaults"> > > <str name="hl.tag.pre"><![CDATA[ > > <b style="background:yellow">,<b > > style="background:lawgreen">, > > <b style="background:aquamarine">,<b > > style="background:magenta">, > > <b style="background:palegreen">,<b > > style="background:coral">, > > <b style="background:wheat">,<b style="background:khaki">, > > <b style="background:lime">,<b > > style="background:deepskyblue">]]></str> > > <str name="hl.tag.post"><![CDATA[</b>]]></str> > > </lst> > > </fragmentsBuilder> > > > > <boundaryScanner name="default" > > default="true" > > class="solr.highlight.SimpleBoundaryScanner"> > > <lst name="defaults"> > > <str name="hl.bs.maxScan">10</str> > > <str name="hl.bs.chars">.,!? 	 </str> > > </lst> > > </boundaryScanner> > > > > <boundaryScanner name="breakIterator" > > > class="solr.highlight.BreakIteratorBoundaryScanner"> > > <lst name="defaults"> > > <!-- type should be one of CHARACTER, WORD(default), LINE and > > SENTENCE --> > > <str name="hl.bs.type">WORD</str> > > <!-- language and country are used when constructing Locale > > object. --> > > <!-- And the Locale object will be used when getting instance > of > > BreakIterator --> > > <str name="hl.bs.language">en</str> > > <str name="hl.bs.country">US</str> > > </lst> > > </boundaryScanner> > > </highlighting> > > </searchComponent> > > > > <!-- Update Processors > > > > Chains of Update Processor Factories for dealing with Update > > Requests can be declared, and then used by name in Update > > Request Processors > > > > http://wiki.apache.org/solr/UpdateRequestProcessor > > > > --> > > > > <!-- The Bob update request processor that creates and populates the > > security boolean fields --> > > <updateRequestProcessorChain name="BobChain" default="true"> > > <processor > > class="com.mydom.solrBob.factory.BobUpdateRequestProcessorFactory" /> > > <processor class="solr.LogUpdateProcessorFactory" /> > > <processor class="solr.RunUpdateProcessorFactory" /> > > </updateRequestProcessorChain> > > > > <!-- Add unknown fields to the schema > > > > An example field type guessing update processor that will > > attempt to parse string-typed field values as Booleans, Longs, > > Doubles, or Dates, and then add schema fields with the guessed > > field types. > > > > This requires that the schema is both managed and mutable, by > > declaring schemaFactory as ManagedIndexSchemaFactory, with > > mutable specified as true. > > > > See http://wiki.apache.org/solr/GuessingFieldTypes > > --> > > <updateRequestProcessorChain name="add-unknown-fields-to-the-schema"> > > <!-- UUIDUpdateProcessorFactory will generate an id if none is > present > > in the incoming document --> > > <processor class="solr.UUIDUpdateProcessorFactory" /> > > > > <processor > > class="com.mydom.solrBob.factory.BobUpdateRequestProcessorFactory" /> > > > > <processor class="solr.LogUpdateProcessorFactory"/> > > <processor class="solr.DistributedUpdateProcessorFactory"/> > > <processor class="solr.RemoveBlankFieldUpdateProcessorFactory"/> > > <processor class="solr.FieldNameMutatingUpdateProcessorFactory"> > > <str name="pattern">[^\w-\.]</str> > > <str name="replacement">_</str> > > </processor> > > <processor class="solr.ParseBooleanFieldUpdateProcessorFactory"/> > > <processor class="solr.ParseLongFieldUpdateProcessorFactory"/> > > <processor class="solr.ParseDoubleFieldUpdateProcessorFactory"/> > > <processor class="solr.ParseDateFieldUpdateProcessorFactory"> > > <arr name="format"> > > <str>yyyy-MM-dd'T'HH:mm:ss.SSSZ</str> > > <str>yyyy-MM-dd'T'HH:mm:ss,SSSZ</str> > > <str>yyyy-MM-dd'T'HH:mm:ss.SSS</str> > > <str>yyyy-MM-dd'T'HH:mm:ss,SSS</str> > > <str>yyyy-MM-dd'T'HH:mm:ssZ</str> > > <str>yyyy-MM-dd'T'HH:mm:ss</str> > > <str>yyyy-MM-dd'T'HH:mmZ</str> > > <str>yyyy-MM-dd'T'HH:mm</str> > > <str>yyyy-MM-dd HH:mm:ss.SSSZ</str> > > <str>yyyy-MM-dd HH:mm:ss,SSSZ</str> > > <str>yyyy-MM-dd HH:mm:ss.SSS</str> > > <str>yyyy-MM-dd HH:mm:ss,SSS</str> > > <str>yyyy-MM-dd HH:mm:ssZ</str> > > <str>yyyy-MM-dd HH:mm:ss</str> > > <str>yyyy-MM-dd HH:mmZ</str> > > <str>yyyy-MM-dd HH:mm</str> > > <str>yyyy-MM-dd</str> > > </arr> > > </processor> > > <processor class="solr.AddSchemaFieldsUpdateProcessorFactory"> > > <str name="defaultFieldType">strings</str> > > <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">tdates</str> > > </lst> > > <lst name="typeMapping"> > > <str name="valueClass">java.lang.Long</str> > > <str name="valueClass">java.lang.Integer</str> > > <str name="fieldType">tlongs</str> > > </lst> > > <lst name="typeMapping"> > > <str name="valueClass">java.lang.Number</str> > > <str name="fieldType">tdoubles</str> > > </lst> > > </processor> > > <processor class="solr.RunUpdateProcessorFactory"/> > > </updateRequestProcessorChain> > > > > <!-- Deduplication > > > > An example dedup update processor that creates the "id" field > > on the fly based on the hash code of some other fields. This > > example has overwriteDupes set to false since we are using the > > id field as the signatureField and Solr will maintain > > uniqueness based on that anyway. > > > > --> > > <!-- > > <updateRequestProcessorChain name="dedupe"> > > <processor class="solr.processor.SignatureUpdateProcessorFactory"> > > <bool name="enabled">true</bool> > > <str name="signatureField">id</str> > > <bool name="overwriteDupes">false</bool> > > <str name="fields">name,features,cat</str> > > <str name="signatureClass">solr.processor.Lookup3Signature</str> > > </processor> > > <processor class="solr.LogUpdateProcessorFactory" /> > > <processor class="solr.RunUpdateProcessorFactory" /> > > </updateRequestProcessorChain> > > --> > > > > <!-- Language identification > > > > This example update chain identifies the language of the incoming > > documents using the langid contrib. The detected language is > > written to field language_s. No field name mapping is done. > > The fields used for detection are text, title, subject and > > description, > > making this example suitable for detecting languages form > full-text > > rich documents injected via ExtractingRequestHandler. > > See more about langId at > > http://wiki.apache.org/solr/LanguageDetection > > --> > > <!-- > > <updateRequestProcessorChain name="langid"> > > <processor > > > class="org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessorFactory"> > > <str name="langid.fl">text,title,subject,description</str> > > <str name="langid.langField">language_s</str> > > <str name="langid.fallback">en</str> > > </processor> > > <processor class="solr.LogUpdateProcessorFactory" /> > > <processor class="solr.RunUpdateProcessorFactory" /> > > </updateRequestProcessorChain> > > --> > > > > <!-- Script update processor > > > > This example hooks in an update processor implemented using > JavaScript. > > > > See more about the script update processor at > > http://wiki.apache.org/solr/ScriptUpdateProcessor > > --> > > <!-- > > <updateRequestProcessorChain name="script"> > > <processor class="solr.StatelessScriptUpdateProcessorFactory"> > > <str name="script">update-script.js</str> > > <lst name="params"> > > <str name="config_param">example config parameter</str> > > </lst> > > </processor> > > <processor class="solr.RunUpdateProcessorFactory" /> > > </updateRequestProcessorChain> > > --> > > > > <!-- Response Writers > > > > http://wiki.apache.org/solr/QueryResponseWriter > > > > Request responses will be written using the writer specified by > > the 'wt' request parameter matching the name of a registered > > writer. > > > > The "default" writer is the default and will be used if 'wt' is > > not specified in the request. > > --> > > <!-- The following response writers are implicitly configured unless > > overridden... > > --> > > <!-- > > <queryResponseWriter name="xml" > > default="true" > > class="solr.XMLResponseWriter" /> > > <queryResponseWriter name="json" class="solr.JSONResponseWriter"/> > > <queryResponseWriter name="python" > class="solr.PythonResponseWriter"/> > > <queryResponseWriter name="ruby" class="solr.RubyResponseWriter"/> > > <queryResponseWriter name="php" class="solr.PHPResponseWriter"/> > > <queryResponseWriter name="phps" > > class="solr.PHPSerializedResponseWriter"/> > > <queryResponseWriter name="csv" class="solr.CSVResponseWriter"/> > > <queryResponseWriter name="schema.xml" > > class="solr.SchemaXmlResponseWriter"/> > > --> > > > > <queryResponseWriter name="json" class="solr.JSONResponseWriter"> > > <!-- For the purposes of the tutorial, JSON responses are written as > > plain text so that they are easy to read in *any* browser. > > If you expect a MIME type of "application/json" just remove this > > override. > > --> > > <str name="content-type">text/plain; charset=UTF-8</str> > > </queryResponseWriter> > > > > <!-- > > Custom response writers can be declared as needed... > > --> > > <queryResponseWriter name="velocity" > class="solr.VelocityResponseWriter" > > startup="lazy"> > > <str name="template.base.dir">${velocity.template.base.dir:}</str> > > <str > > > name="solr.resource.loader.enabled">${velocity.solr.resource.loader.enabled:true}</str> > > <str > > > name="params.resource.loader.enabled">${velocity.params.resource.loader.enabled:false}</str> > > </queryResponseWriter> > > > > <!-- XSLT response writer transforms the XML output by any xslt file > found > > in Solr's conf/xslt directory. Changes to xslt files are checked > for > > every xsltCacheLifetimeSeconds. > > --> > > <queryResponseWriter name="xslt" class="solr.XSLTResponseWriter"> > > <int name="xsltCacheLifetimeSeconds">5</int> > > </queryResponseWriter> > > > > <!-- Query Parsers > > > > http://wiki.apache.org/solr/SolrQuerySyntax > > > > Multiple QParserPlugins can be registered by name, and then > > used in either the "defType" param for the QueryComponent (used > > by SearchHandler) or in LocalParams > > --> > > <!-- example of registering a query parser --> > > <!-- > > <queryParser name="myparser" class="com.mycompany.MyQParserPlugin"/> > > --> > > > > <!-- Function Parsers > > > > http://wiki.apache.org/solr/FunctionQuery > > > > Multiple ValueSourceParsers can be registered by name, and then > > used as function names when using the "func" QParser. > > --> > > <!-- example of registering a custom function parser --> > > <!-- > > <valueSourceParser name="myfunc" > > class="com.mycompany.MyValueSourceParser" /> > > --> > > > > > > <!-- Document Transformers > > http://wiki.apache.org/solr/DocTransformers > > --> > > <!-- > > Could be something like: > > <transformer name="db" > > class="com.mycompany.LoadFromDatabaseTransformer" > > > <int name="connection">jdbc://....</int> > > </transformer> > > > > To add a constant value to all docs, use: > > <transformer name="mytrans2" > > class="org.apache.solr.response.transform.ValueAugmenterFactory" > > > <int name="value">5</int> > > </transformer> > > > > If you want the user to still be able to change it with > > _value:something_ use this: > > <transformer name="mytrans3" > > class="org.apache.solr.response.transform.ValueAugmenterFactory" > > > <double name="defaultValue">5</double> > > </transformer> > > > > If you are using the QueryElevationComponent, you may wish to mark > > documents that get boosted. The > > EditorialMarkerFactory will do exactly that: > > <transformer name="qecBooster" > > class="org.apache.solr.response.transform.EditorialMarkerFactory" /> > > --> > > > > > > <!-- Legacy config for the admin interface --> > > <admin> > > <defaultQuery>*:*</defaultQuery> > > </admin> > > > > </config> > > > > On Tue, Jan 19, 2016 at 1:06 PM, Erick Erickson <erickerick...@gmail.com > > > > wrote: > > > >> Let's see your solrconfig.xml, because it does look like you're > >> somehow using managed schema. > >> > >> And is the error above from the Solr log or your client? Because > >> the Solr log often has more complete information. > >> > >> Best, > >> Erick > >> > >> On Tue, Jan 19, 2016 at 9:54 AM, Bob Lawson <bwlawson...@gmail.com> > wrote: > >> > I added some fields to schema.xml. I then use a custom extension of > >> > UpdateRequestProcessor to add those fields to a document being > indexed. > >> > When I run the post command, I am getting an error because apparently > >> Solr > >> > is trying to add more fields over and above what I manually added. > Here > >> is > >> > the error: > >> > > >> > > >> > > >> > > >> > > >> > > >> > *15726 ERROR (qtp1450821318-13) [ x:test] o.a.s.h.RequestHandlerBase > >> > org.apache.solr.common.SolrException: This IndexSchema is not mutable. > >> > at > >> > > >> > org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:271) > >> > at > >> > > >> > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:49) > >> > at > >> > > >> > org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)* > >> > Questions: > >> > > >> > 1) I thought Solr would only attempt to modify the schema when > running in > >> > managed schema mode, which I am not. Why is Solr trying to modify > >> > schema.xml? > >> > 2) What fields is it trying to add? I confirmed that I manually added > >> all > >> > necessary fields to support my UpdateRequestProcessor extension. > >> > > >> > Thanks for the help! > >> >
