Type: New Feature
Affects Version/s: 4.4
Fix Version/s: None
Component/s: Schema and Analysis
As of Solr 4.4, the Solr Schema Rest API provides read access to all schema elements (
SOLR-4503, SOLR-4658, SOLR-4537, SOLR-4623), and the ability to dynamically add new fields ( SOLR-3251). See the wiki for documentation: http://wiki.apache.org/solr/SchemaRESTAPI.
This is an umbrella issue to capture all future additions to the schema REST API, including:
- adding dynamic fields
- adding field types
- adding copy field directives
- enabling wholesale replacement by PUTing a new schema.
- modifying fields, dynamic fields, field types, and copy field directives
- removing fields, dynamic fields, field types, and copy field directives
- modifying all remaining aspects of the schema: Name, Version, Unique Key, Global Similarity, and Default Query Operator
I think the first three will be the easiest.
The main use case for further modifications to the Schema API is to offer a new default schema lifecycle to replace the current schema lifecycle (in which users manually edit a local copy of schema.xml, then overwrite the authoritative schema.xml file – on local disk or in ZooKeeper – and then reload or restart Solr), to allow for the schema API to perform all schema edit operations. It's important to note that the current default schema lifecycle will continue to be supported, even after it is no longer the default: people will always be able to directly edit schema.xml, although if they choose to do so, they won't be able to use the Schema API methods that modify the schema.
Before Solr can switch the default schema configuration to ManagedIndexSchema, which is a prerequisite for all Schema API methods that modify the schema, everything that the current default schema lifecycle supports must be supported by the Schema API.
The blocking issue for switching to the default schema configuration to ManagedIndexSchema, minimally, is allowing wholesale schema replacement via the Schema API – this is essentially support for the current schema lifecycle, with the additional requirement that users go through the Schema API. The read side of the schema lifecycle, i.e. getting the current live schema, is already implemented.