Why did they create the concept of “schema.xml” in Solr?

Question

Lucene does searching and indexing, all by taking "coding"... Why doesn't Solr do the same ? Why do we need a schema.xml ? Whats its importance ? Is there a way to avoid placing all the fields we want into a schema.xml ? ( I guess dynamic fields are the way to go, right ? )

Answer 1

That's just the way it was built. Lucene is a library, so you link your code against it. Solr, on the other hand, is a server, and in some cases you can just use it with very little coding (eg using DataImportHandler to index and Velocity plugin to browse and search).

The schema allows you to declaratively define how each field is analyzed and queried.

If you want a schema-less server based on Lucene, take a look at ElasticSearch .

Answer 2

If you want to avoid constantly tweaking your schema.xml, then dynamic fields are indeed the way to go. For an example, I like the Sunspot schema.xml — it uses dynamic fields to set up type-based naming conventions in field names.

https://github.com/outoftime/sunspot/blob/master/sunspot/solr/solr/conf/schema.xml

Based on this schema, a field named content_text would be parsed as a text field:

<dynamicField name="*_text" stored="false" type="text" multiValued="true" indexed="true"/>

Which corresponds to its earlier definition of the text fieldType .

Most schema.xml files that I work with start off based on the Sunspot schema. I have found that you can save a lot of time by establishing and reusing a good convention in your schema.xml.

Answer 3

Solr acts as a stand-alone search server and can be configured with no coding. You can think of it as a front-end for Lucene. The purspose of the schema.xml file is to define your index.

If possible, I would suggest defining all your fields in the schema file. This gives you greater control over how those fields are indexed and it will allow you to take advantage of copy fields (if you need them).