[
https://issues.apache.org/jira/browse/SOLR-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385550#comment-14385550
]
Shawn Heisey commented on SOLR-7316:
------------------------------------
There's a LOT of legacy baggage ... Solr has been around for more than ten
years, Lucene for several years longer. When you're in the trenches, you might
not even notice it's there ... so when new features are implemented, that work
is often done without thinking about legacy APIs.
When we DO notice divergence between new functionality and legacy baggage, we
try to rectify the situation, but the work required is difficult and huge, and
tends to be very hard to keep in sync with the work that other people are doing
at the same time.
bq. I have no idea where the config comes from, nor do I care.
I would wager that this point of view will not survive beyond your first
production deployment. The expert users definitely care, and they do not want
that to be controlled by us, they want it to be controlled by them. Can we do
better, and give users a place to put the config they'll get by default? You
bet we can, and I think you'll probably see that in the near future.
bq. The most annoying thing by far about tis API is that, Solr does include a
perfectly good default configuration in "basic_configs". In fact, when you use
`solr create -c foo`, IT USES THAT DEFAULT CONFIGURATION! So why doesn't the
CREATE API also use the same default configuration? What's the huge difference?
The bin/solr script is a very recent innovation. It first appeared in 4.10.0,
and only in 5.0.0 has it started to become usable. The "basic_configs"
directory doesn't exist in any of the Solr versions that I currently use in
production, which are 4.2.1, 4.6.1, 4.7.2. and 4.9.1. It was created as part
of the startup script work. The bin/solr script knows how to use basic_configs
... but the Solr internal APIs have absolutely no idea that it exists.
We are in the process of making Solr into a completely standalone application
that is fully aware of absolutely everything contained in its directory
structure, but we are hogtied by dependence on historical truths in the current
implementation. The bin/solr script is the first step in that migration.
I'm aware that all I'm really giving here is excuses. We are aware of many
deficiencies that we want to correct, and users inform us of problems we might
not have known about. It takes time to correct course on a large project like
Solr.
> API to create a core is broken
> ------------------------------
>
> Key: SOLR-7316
> URL: https://issues.apache.org/jira/browse/SOLR-7316
> Project: Solr
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.0
> Reporter: Mark Haase
>
> *Steps To Reproduce*
> {code}
> curl
> 'http://localhost:8983/solr/admin/cores?action=CREATE&name=new_core&instanceDir=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
> by: Can't find resource 'solrconfig.xml' in classpath or
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, yes. The thing to remember here is that you're using a much
> older approach that had its roots in the pre-cloud days.
> {quote}
> *The whole point of creating APIs is to abstract out details that the caller
> doesn't need to know, and yet this API requires an understanding of Solr's
> internal file structure and history of the project?* I'm speechless.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
