[
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091912#comment-14091912
]
Shawn Heisey commented on SOLR-3619:
------------------------------------
I skimmed the existing discussion, didn't read it closely. I expect I will be
restating many things that have already been said:
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, 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.
The managed schema mode has a lot of promise, but there are holes in its
functionality. Once those holes are patched so that editing the actual
schema.xml file is never required, it will be awesome. I can envision a
section of the admin UI where fieldTypes, fields, and other schema settings can
be constructed or edited easily. If a change requires a reindex, the UI can
notify the user.
I assume that Cassandra's complaints about the ZK tools refers mostly to zkcli.
If so, I agree ... it is difficult to use, clunky, and intimidating ... but
using it produces the best results. Relying on bootstrap system properties
causes a lot of problems for new users when they try to move to production.
I'd like to see an extensive admin UI interface for uploading, changing,
cloning, and deleting config sets.
Because of the security concerns that Redhat raised with the "edit the config
files" UI we used to have, zookeeper config modifying functionality must be
disabled by default, with some way of enabling it that requires administrative
access to the operating system. That might be the presence of a
specifically-named file in the solr home, which you can create or delete to
enable/disable the functionality without restarting Solr. My initial thought
was an option in solr.xml, but because solr.xml itself can be located in
zookeeper, that would create a chicken/egg problem.
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.
In general, I like what Hoss has proposed. If any specific objections arise as
we get closer to implementation and release, I expect I'll be able to raise
them then.
> 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
