[
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14067950#comment-14067950
]
Jack Krupansky commented on SOLR-3619:
--------------------------------------
bq. a database like MySQL
But Solr isn't a database! (Nor is Elasticsearch.)
I think part of the issue here is that there are two distinct use cases: single
core and multi-core, or single collection and multiple collection. Solr is
perfectly usable in single-core/collection mode - the user need not concern
themselves with naming a collection. In that case, the fact that there is this
extra level of abstraction called a "collection" and it is named "collection1"
is a bit of an annoyance and distraction, so the less annoying the better.
Forcing the user to come up with a name and perform an extract step of naming
that default collection adds no significant value for the
single-core-collection use case, or the onboarding or introduction of new users
to Solr as "a simple but powerful search platform."
Sure, once the user has decided that they indeed have the multi-core/collection
use case, THEN they will want to name their cores/collections with "real"
names. Sure, by all means make support for this use case as clean and
convenient as possible.
Why not simply give the user a choice, up front, and let them decide for
themselves what use case they want? Whether that is a separate download or a
separate startup command or a separate start directory seems like more of a
detail than an architectural choice for de-supporting one useful use case.
I would say leave the current "example" where it is, as it is, and have a
separate, clean download for "multi-collection server" mode. I'm sure people
deploying SolrCloud clusters in the cloud would appreciate the latter, without
any burden of example and tutorial fluff.
And maybe the use case distinction is simply SolrCloud vs. traditional Solr.
And then for the new (5.0) SolrCloud server mode, we can have a little script
for "quick demo mode" that is more like the current example/collection1 setup -
or a separate example/introduction/tutorial download from the raw server
download.
In short, don't sacrifice the current simplicity, but do pursue the 5.0 server
mode.
Maybe if progress were made on the 5.0 Solr "server", some of these details
would just fall out or at least be more obvious and non-controversial.
As it is, this is feeling a lot more like "rearranging deck chairs on the
Titanic" than helping Solr to leapfrog to a whole new level in either
"server-ness" or "ease-of-use-ness."
BTW, has any thought been given to including a packaging of the 5.0 Solr server
as a "Windows service"? That might also help to clarify some of this packaging
stuff.
> Rename 'example' dir to 'server' and pull examples into an 'examples'
> directory
> -------------------------------------------------------------------------------
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
> Issue Type: Improvement
> Reporter: Mark Miller
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, server-name-layout.png
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
