[jira] [Commented] (SOLR-15312) v2 api: core creation, config vs configSet params

["Jason Gerlowski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-15312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363763#comment-17363763 ] 

Jason Gerlowski commented on SOLR-15312:
----------------------------------------

bq. Granted back-compat on an API almost nobody uses yet is dubious but still.

I wonder if we could give v2 some sort of "experimental" designation to free ourselves from these sort of back-compat concerns.  I would be very surprised if anyone uses it for more than loose experimentation.  Not only has it been mostly undocumented in the ref-guide until recently - it's still largely unsupported in SolrJ.

Being able to fix warts like the mapping issue you found without having to worry about backcompat etc. would greatly simplify and speed bringing v2 up to parity. (And I suspect would hurt very very few users.)  

> v2 api: core creation, config vs configSet params
> -------------------------------------------------
>
>                 Key: SOLR-15312
>                 URL: https://issues.apache.org/jira/browse/SOLR-15312
>             Project: Solr
>          Issue Type: Bug
>          Components: v2 API
>            Reporter: David Smiley
>            Priority: Blocker
>             Fix For: main (9.0)
>
>
> I tried to follow our [ref guide's instructions|https://solr.apache.org/guide/8_8/config-sets.html#configsets-in-standalone-mode] on how to create a core with a certain configSet using the V2 API.  It has me specify the "configSet" param.  But it does not work... the generated core.properties file contains the "configSet" reference and unexpectedly a "config" reference.  Since I have a normally named solrconfig.xml, this fails core creation.
> I figured out the bug is here: https://github.com/apache/solr/blob/4e90e48ac29ee38662c04fcf7815d5170ceb2669/solr/solrj/src/java/org/apache/solr/client/solrj/request/CoreApiMapping.java#L43 which maps "config" to "configSet".  But these are distinct things.  If you were to [introspect the core creation api|http://localhost:8983/api/cores/_introspect?command=create] you would see these two parameter definitions:
> {code}
> "config":{
>               "type":"string",
>               "description":"Name of the config file (i.e., solrconfig.xml) relative to instanceDir. If you are using the default name (solrconfig.xml), you do not need to define the config file name."},
>             "configSet":{
>               "type":"string",
>               "documentation":"https://lucene.apache.org/solr/guide/config-sets.html",
>               "description":"The name of a config set to use. The config set must already exist. The solr.xml file defines the location of the configset base directory, and configuration files can be shared between cores by defining sub-directories. The files in the named configSet will be used for the schema and config properties instead of defining them explicitly."},
> {code}
> There is also a "schema" param for the file name of the schema.
> I see two courses of action.  One keeps the current introspect API and is trivially implemented at the line of code I showed, replacing the mapping with null.  Or, use "config" for the configSet, and rename "config" and "schema" params to "configFile" and "schemaFile" respectively (or some other names).  The point of the latter is to align SolrCloud with standalone API on the semantics of what "config" refers to.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org