Managed Resources

To begin, you need to define a field type that uses the ManagedStopFilterFactory, such as:

There are two important things to notice about this field type definition:

The REST endpoint for managing the English stop words in the techproducts collection is: /solr/techproducts/schema/analysis/stopwords/english.

The example resource path should be mostly self-explanatory. It should be noted that the ManagedStopFilterFactory implementation determines the /schema/analysis/stopwords part of the path, which makes sense because this is an analysis component defined by the schema.

It follows that a field type that uses the following filter:

would resolve to path: /solr/techproducts/schema/analysis/stopwords/french.

So now let’s see this API in action, starting with a simple GET request:

Assuming you sent this request to Solr, the response body is a JSON document:

The sample_techproducts_configs configset ships with a pre-built set of managed stop words, however you should only interact with this file using the API and not edit it directly.

One thing that should stand out to you in this response is that it contains a managedList of words as well as initArgs. This is an important concept in this framework — managed resources typically have configuration and data. For stop words, the only configuration parameter is a boolean that determines whether to ignore the case of tokens during stop word filtering (ignoreCase=true|false). The data is a list of words, which is represented as a JSON array named managedList in the response.

Now, let’s add a new word to the English stop word list using an HTTP PUT:

Here we’re using curl to PUT a JSON list containing a single word “foo” to the managed English stop words set. Solr will return 200 if the request was successful. You can also put multiple words in a single PUT request.

You can test to see if a specific word exists by sending a GET request for that word as a child resource of the set, such as:

This request will return a status code of 200 if the child resource (foo) exists or 404 if it does not exist the managed list.

To delete a stop word, you would do:

For the most part, the API for managing synonyms behaves similar to the API for stop words, except instead of working with a list of words, it uses a map, where the value for each entry in the map is a set of synonyms for a term. As with stop words, the sample_techproducts_configs configset includes a pre-built set of synonym mappings suitable for the sample data that is activated by the following field type definition:

To get the map of managed synonyms, send a GET request to:

This request will return a response that looks like:

Managed synonyms are returned under the managedMap property which contains a JSON Map where the value of each entry is a set of synonyms for a term, such as "happy" has synonyms "glad" and "joyful" in the example above.

To add a new synonym mapping, you can PUT/POST a single mapping such as:

The API will return status code 200 if the PUT request was successful. To determine the synonyms for a specific term, you send a GET request for the child resource, such as /schema/analysis/synonyms/english/mad would return ["angry","upset"].

You can also PUT a list of symmetric synonyms, which will be expanded into a mapping for each term in the list. For example, you could PUT the following list of symmetric synonyms using the JSON list syntax instead of a map:

Note that the expansion is performed when processing the PUT request so the underlying persistent state is still a managed map. Consequently, if after sending the previous PUT request, you did a GET for /schema/analysis/synonyms/english/jocular, then you would receive a list containing ["funny", "entertaining", "whimiscal"]. Once you’ve created synonym mappings using a list, each term must be managed separately.

Lastly, you can delete a mapping by sending a DELETE request to the managed endpoint.