You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Steve Rowe (JIRA)" <ji...@apache.org> on 2013/08/12 19:00:53 UTC
[jira] [Updated] (SOLR-4898) Flesh out the Schema REST API
[ https://issues.apache.org/jira/browse/SOLR-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve Rowe updated SOLR-4898:
-----------------------------
Description:
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.
was:
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.
> Flesh out the Schema REST API
> -----------------------------
>
> Key: SOLR-4898
> URL: https://issues.apache.org/jira/browse/SOLR-4898
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
> Affects Versions: 4.4
> Reporter: Steve Rowe
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org