[ 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