[jira] [Commented] (SOLR-5104) Remove Default Core
[ https://issues.apache.org/jira/browse/SOLR-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727423#comment-13727423 ] Grant Ingersoll commented on SOLR-5104: --- +1 to removing default core. Remove Default Core --- Key: SOLR-5104 URL: https://issues.apache.org/jira/browse/SOLR-5104 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Fix For: 5.0 I see no reason to maintain the notion of a default Core/Collection. We can either default to Collection1, or just simply create a core on the fly based on the client's request. Thus, all APIs that are accessing a core would require the core to be in the address path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5104) Remove Default Core
[ https://issues.apache.org/jira/browse/SOLR-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727053#comment-13727053 ] Mark Miller commented on SOLR-5104: --- We certainly want to do this, and I don't consider it removing a feature. It's purely an improvement IMO. The main reason I have not pushed for it yet was that the it killed the admin UI - but now that that is fixed, this is the next step. This is a relic from the pre multi core days - when Solr was one index and that is it. Backcompat sludge is what has kept it around IMO - we want to act like most systems and start empty. It should be very simple for a user to create his first collection, but he should be the one to name it. As Grant mentions, this is certainly what you want for scriptibility, and it's more consistent with other systems for users as well. A new user should: 1. Start Solr 2. Name and create their first collection. When they want more collections, repeat step 2, a step they learned right away. Remove Default Core --- Key: SOLR-5104 URL: https://issues.apache.org/jira/browse/SOLR-5104 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Fix For: 5.0 I see no reason to maintain the notion of a default Core/Collection. We can either default to Collection1, or just simply create a core on the fly based on the client's request. Thus, all APIs that are accessing a core would require the core to be in the address path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5104) Remove Default Core
[ https://issues.apache.org/jira/browse/SOLR-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727060#comment-13727060 ] Mark Miller commented on SOLR-5104: --- Took me a moment for me to realize that is not referring to removing the core that ships with Solr, but the default core feature. I want to remove the actual default core that is setup, so certainly +1 on dropping this. I think we already discussed it some for 5.0. Remove Default Core --- Key: SOLR-5104 URL: https://issues.apache.org/jira/browse/SOLR-5104 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Fix For: 5.0 I see no reason to maintain the notion of a default Core/Collection. We can either default to Collection1, or just simply create a core on the fly based on the client's request. Thus, all APIs that are accessing a core would require the core to be in the address path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5104) Remove Default Core
[ https://issues.apache.org/jira/browse/SOLR-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726483#comment-13726483 ] Jack Krupansky commented on SOLR-5104: -- Minor procedural nit... If you intend to remove a feature, deprecate it first (like, in 4.5.) Thanks! Remove Default Core --- Key: SOLR-5104 URL: https://issues.apache.org/jira/browse/SOLR-5104 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Fix For: 5.0 I see no reason to maintain the notion of a default Core/Collection. We can either default to Collection1, or just simply create a core on the fly based on the client's request. Thus, all APIs that are accessing a core would require the core to be in the address path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5104) Remove Default Core
[ https://issues.apache.org/jira/browse/SOLR-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726495#comment-13726495 ] Jack Krupansky commented on SOLR-5104: -- bq. I see no reason to maintain the notion of a default Core/Collection. Okay, here is the reason... It is a great convenience and shortens URLs to make them more readable and easier to type. It greatly facilitates prototyping and experimentation and learning of the basics of Solr. And... compatibility with existing apps. So, this notion that there isn't any reason is complete nonsense. OTOH, maybe you are trying to suggest that there is some reason or valuable benefit to be gained by requiring explicit collection/core name in the URL path. But, you have not done so. Not a hint of any reason or benefit. So, if you do have a reason or perceived benefit for eliminating a great convenience feature, please disclose it. Or... is this not so much an issue of reason as because some code or tool change you are contemplating does not support the kind of flexible URL syntax that Solr supports? Well, if the benefits of the change in technology outweigh the loss of a valuable feature, then that is worth considering, but as of this moment no positive tradeoff has been proposed or established. OTOH, if there were a determined effort to give Solr a full-blown true REST API and THAT was the motive for explicit collection name, I'd be 100% all for it. Side note: Maybe collection1 should become example to make it clear that real apps should assign an app-meaningful name rather than leaving it as collection1. Remove Default Core --- Key: SOLR-5104 URL: https://issues.apache.org/jira/browse/SOLR-5104 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Fix For: 5.0 I see no reason to maintain the notion of a default Core/Collection. We can either default to Collection1, or just simply create a core on the fly based on the client's request. Thus, all APIs that are accessing a core would require the core to be in the address path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5104) Remove Default Core
[ https://issues.apache.org/jira/browse/SOLR-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726503#comment-13726503 ] Grant Ingersoll commented on SOLR-5104: --- My reason is b/c SolrDispatchFilter is filled with legacy cruft, this being one of them. The simpler and more standard we can make all path handling, the better. I don't really care much about shorter URLs and I don't buy the prototyping/learning factor. In fact, I'd argue that it is harder b/c of it, since you have a magic core and than all of your other cores. If you just make the name of the collection part of the path always, there is no more guessing. The less legacy code for plumbing we carry forward in 5, the better off Solr we will be. And yes, I am working on making the possibility of a full blown REST API. See SOLR-5091. Remove Default Core --- Key: SOLR-5104 URL: https://issues.apache.org/jira/browse/SOLR-5104 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Fix For: 5.0 I see no reason to maintain the notion of a default Core/Collection. We can either default to Collection1, or just simply create a core on the fly based on the client's request. Thus, all APIs that are accessing a core would require the core to be in the address path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
