Have you ever wonder how to avoid accidental, or on purpose, modification of collection data? Of course, we could reject access as one of the possible solutions, but it is not always possible. In today's blog post, we will look into how to easily protect your collection from accidental modifications by setting it to read-only.

You may also like:  Java 10 Immutable/Unmodifiable Stream API Collectors

Default Behavior

When we create the collection, either via the API or using the script, it is created in the all-access mode — you can both read data from it and write data to it. Let's create a collection using the following command:

$ bin/solr create_collection -c readonly

We are working with Solr 8.2, so Solr will use the configuration called  _default that is available in SolrCloud and used when no collection is specified. It allows us to index a simple document using the following command:

$ curl -XPOST -H 'Content-Type:application/json' 'http://localhost:8983/solr/readonly/update' -d '[
  {
   "id" : 1,
   "name" : "Test document"
  }
 ]'

In response, Solr will tell us that indexing went well; the document was processed and indexed properly:

Read-Only Collection

If we would like our created collection to be read-only so that we can't write data to it, we would have to set the readOnly attribute of that collection to value. To do that, we will use the Collections API with the following command:

$ curl -XGET 'localhost:8983/solr/admin/collections?action=MODIFYCOLLECTION&collection=readonly&readOnly=true'

Response from Solr after the above command should look as follows:

{
   "responseHeader":{
     "status":0,
     "QTime":846},
   "success":{
     "192.168.0.20:8983_solr":{
       "responseHeader":{
         "status":0,
         "QTime":724}}}}

Let's test if that read-only mode works and how it works.

Let's start with simple indexing by using the following command:

$ curl -XPOST -H 'Content-Type:application/json' 'http://localhost:8983/solr/readonly/update' -d '[
  {
   "id" : 2,
   "name" : "Second test document"
  }
 ]

In this case, Solr will return an error similar to the following one:

{
   "responseHeader":{
     "status":403,
     "QTime":1},
   "error":{
     "metadata":[
       "error-class","org.apache.solr.common.SolrException",
       "root-error-class","org.apache.solr.common.SolrException"],
     "msg":"Collection readonly is read-only.",
     "code":403}}

What if we would like to use the Schema API to add a new field? Let's test it by using the following command:

$ curl -XPOST -H 'Content-type:application/json' 'http://localhost:8983/solr/readonly/schema' --data-binary '{
  "add-field" : {
   "name" : "test",
   "type" : "string",
   "stored" : true,
   "indexed" : true
  }
 }'

In this case, the operation is successful:

{
   "responseHeader":{
     "status":0,
     "QTime":479}}

Enabling Modifications

In order to turn off collection read-only mode, and once again, allow modifications, we need to use the Collections API one again and set the readOnly attribute of the collection tofalse:

$ curl -XGET 'localhost:8983/solr/admin/collections?action=MODIFYCOLLECTION&collection=readonly&readOnly=false'

Summary

As we can see in the above example with Solr 8.1, we witnessed a simple yet useful method of protection of the documents inside the collection. If our application uses a collection that can be set as read-only, it is really worth considering.

By using read-only collections, we can save ourselves potential problems of accidental data write in case of errors on our application side. With authorization and authentication available in SolrCloud, we can also limit access to the Collections API and turn off the possibility of setting the read-only mode to unauthorized persons, adding yet another layer of security to our cluster. Think about the possibilities!

Further Reading

Using Apache Solr in Production

Singleton List Showdown: Collections::singletonList Vs. List::of