[
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088287#comment-14088287
]
Hoss Man commented on SOLR-3619:
--------------------------------
FWIW: I've been deliberately avoiding reading/commenting on most of the issues
like this one for hte past few months, because i've come to realize I've got
far too much vested history to have any real idea what choices for things like
this best serve the "new user experience" with solr.
But since miller called me out explicitly and asked for an opinion, i'll give
one -- but please don't take any of this this as a vote for/against any other
specific, concrete, ideas other people have proposed -- because i still haven't
read most of the comments in this issue since whenever my last comment was.
The main gist i get of the current discussion is about "default" behavior and
schema management -- so here is the pie-in-the-sky opinion of what i personally
think would make a lot of sense in the long run...
* You start solr up the first time, you have 0 collections.
* there are _many_ sample configsets that come with solr, ready to be specified
by name when you create your first collection
** none of the configsets are named "default" or "collection1" - there is no
such thing as a "default" config set, just like there is no such thing as a
"default" collection
** each of the sample config sets has a README file explaining why it's
interesting
** each of the sample config sets has a file/directory of sample data, or a DIH
config file that knows how to index some external data
** the configsets should all be as small as they can possible be, while still
clearly showcasing the thing that they showcase
* a paired down version of the current "collection1" configs would be called
"sample_techproductdata_configs"
** anything in the current configs not directly related to the tech product
example docs would be ripped out
** everything would be tweaked to showcase the best possible configs we could
imagine for the specific sample data usecase (ie: request handler defualts,
spell check configs, velocity UI templates, etc...)
** the first thing in the tutorial would be creating a "tech_products"
collection using this configset, and indexing it's sample data.
** the tutorial would then use the "tech_products" collection to demo some of
the features currently covered in the tutorial (basic search, schema concepts,
faceting, highlighting, etc...)
* another config called "sample_bookdata_configs" would also be much a much
smaller subset of the current "collection1" configs
** it would be paired with books.json & books.csv, have nothing in it unrelated
to books, etc...
** we probably wouldn't need to mention this config set in the tutorial, but
having it available as another example of a purpose created set of configs for
users to compare/contrast with the "sample_techproductdata_configs" would be
useful.
* there would be a configset named "basic_configs"
** this would have the managed-schema enabled (so the REST API could be used to
manipulate the schema) .. as more REST APIs are added moving forward, they
would also be enabled in this config set.
** this would _not_ have the "schemaless" update processors
*** ? or maybe the update processors are there, but in a non-default chain ?
** they key goal here being the most basic configs someone could start with,
and add to, w/o any confusion about what might be cruft they can delete
** the second major section of the tutorial would have the user create two
collections using this configset, and then use those two collections to
showcase the Schema REST APIs to create the same field with different
properties, and then show how the two collections behavior differently with the
same sample data indexed into them.
* there would be a configset named "data_driven_schema_configs"
** this would have all of the "schemaless" bells and whistles enabled
** the tutorial would have the user create a collection using this config to
show off these features, etc...
* there would be many other config sets available, to show off various features
of solr, int isolated specific example configs where they are easier to digest
then the current kitchen sink of pain that we have today.
** every configset would have some JUnit tests to verify that they work, and
that they can load their sample data (even if we aren't testing "curl", we can
test with contentStream and the file path, mock DIH datasources, etc...)
* the world would be full of sunshine and rainbows and free candy.
> 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
> Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, managed-schema,
> server-name-layout.png, solrconfig.xml
>
>
--
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
