[
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092073#comment-14092073
]
Grant Ingersoll commented on SOLR-3619:
---------------------------------------
bq. I can see the value of a "schemaless" mode for a brand-new user or when
initially developing a schema, but when it comes to production, the chances of
an incorrect guess are just too high,
There are actually some use cases for it in production, as Yonik mentioned, but
in reality, I don't think anyone here is proposing that the majority of users
go into production in data-driven schema mode.
bq. and fixing things after an incorrect guess is likely to require a reindex.
On the IRC channel, users are not shy about letting you know just how much they
hate reindexing ... especially if they were not previously aware of what
reindexing actually means. That doesn't really go away when the schema is
explicit, but it would not be as likely.
We aren't talking about re-indexing production. We are talking about rapid
iteration of data modeling. Those who truly need data-driven (and there are
those people out there) will already know the caveats and those who don't
should be guided away from it as they progress by documentation. I like to
break this whole process down into what I consistently see as the selection
process most devs go through when selecting technology (search or otherwise):
# Boss or you or someone else says: hey we need to solve this problem. I think
X and possibly Y will work.
# Boss: You've got one (maybe two) week(s) to make a recommendation
# You then spend that time doing the following for X and Y:
## 5 minute to 1 hour test/tutorial (anything that doesn't pass that gets
tossed)
## 1 day test (can I get my data in and ask the questions I need of it?)
## Spend the rest of the time scaling it up and exploring and peeling back the
layers of the onion (how do I scale? how would I do this in production? what
bumps are in my way?)
# Make a recommendation
# Go for it -- This step is when they start to lock things down.
The thing is, Solr is incredibly awesome at the end stages of this game (i.e.
getting to production). It is way more solid and way more tested, as can be
seen time and time again, but if we don't solve the ease of use stuff, than it
doesn't matter, b/c it isn't being selected to be used in the first place. If
you think about it, easy to get started, easy to get finished is a killer
combination. Solr is easy to get finished already, but it still has a fairly
steep learning curve for people who aren't search experts (which is what has
changed the most recently: more people are looking at Solr as a NoSQL store and
less at it as a search engine).
bq. I'd like to see an extensive admin UI interface for uploading, changing,
cloning, and deleting config sets.
Perhaps for experts, but again, I doubt most users should need to do these
things. Not saying I'm against it, but I think we should minimize any mention
of this stuff until later.
bq. zookeeper config modifying functionality must be disabled by default, with
some way of enabling it that requires administrative access to the operating
system.
I believe there are other APIs that are being worked on that will make editing
the config something one does programmatically, which means it can also be
secured. IMO, the current XML config files, etc., should be an implementation
detail, not an API, as they are now.
bq. I just had an interesting idea. In order for config editing to turn on, we
could require a two-part procedure. First you go to a specific section of the
admin UI where you enter an edit mode expiration time. When that is submitted,
it gives you a filename, most likely containing a hash, like
edit-5fb65b8bfe33f603b7a427284cc6e48a. Until the expire time for that hash is
reached, the presence of that file in the solr home will allow config editing.
We could put a limit on the expiry time of 1-4 hours.
Again, perhaps this is an expert thing and labeled accordingly, but I don't
think new users should have to do this. If we can't make this stuff simpler,
then we shouldn't do it at all.
> 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
