[
https://issues.apache.org/jira/browse/SOLR-10574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986636#comment-15986636
]
Alexandre Rafalovitch commented on SOLR-10574:
----------------------------------------------
I feel that none of the current examples are really _awesome_ anymore, given
the growth and change in Solr. Ideally, we would rebuild the schemas (and
possibly associated tutorials) as per SOLR-10329. But it would be a really big
project, so it is a bit of a dream so far.
More immediate, I think the question is how to do the needed workflow tasks
with whatever schema is chosen. The basic set of features I can think of:
* Create collection (duh)
* Add new fields automatically? (schemaless mode?)
* Add new fields manually (API)
* Remove fields (e.g. when schemaless detection was wrong and needs to be
redone) (API?)
* Add type definitions (API)
* Remove type definitions (API?)
* Modify solrconfig.xml (API, overrides and external paramsets)
* Lock the schema from future modifications (?)
Theoretically, any managed schema can do that, but the question is how easy it
is for the user to understand what is there already and how to modify it for
their own needs.
> Choose a default configset for Solr 7
> -------------------------------------
>
> Key: SOLR-10574
> URL: https://issues.apache.org/jira/browse/SOLR-10574
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Ishan Chattopadhyaya
>
> Currently, the data_driven_schema_configs is the default configset when
> collections are created using the bin/solr script and no configset is
> specified.
> However, that may not be the best choice. We need to decide which is the best
> choice, out of the box, considering many users might create collections
> without knowing about the concept of a configset going forward.
> (See also SOLR-10272)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
