[jira] [Created] (SOLR-13103) UnifiedHighlighter Separator-based BreakIterator should work with Strings, not just a single character
Grant Ingersoll created SOLR-13103: -- Summary: UnifiedHighlighter Separator-based BreakIterator should work with Strings, not just a single character Key: SOLR-13103 URL: https://issues.apache.org/jira/browse/SOLR-13103 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: highlighter Reporter: Grant Ingersoll For the `hl.bs.type` choice of SEPARATOR, it would be nice if we could support not just a single character, but a string. In looking at the code, I see no reason Strings can't be supported other than a few signature changes on some constructors. My use case: I have docs that I have section and page markers that make for conveniently-sized passages for highlighting, but there really isn't any clean way to mark those sections with a single character. For instance, Tika will extract and mark pages with ``. If I could pass in that `` tag as my separator, I could then just highlight within a page. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11963) Map Data Extraction/OCR
Grant Ingersoll created SOLR-11963: -- Summary: Map Data Extraction/OCR Key: SOLR-11963 URL: https://issues.apache.org/jira/browse/SOLR-11963 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Grant Ingersoll NY Public Library has a rather interesting project that might unlock lots of map data for Tika: [https://github.com/nypl-spacetime/map-vectorizer] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11944) Add examples of WKT and GeoJSON Spatial indexing to spatial-search.adoc
[ https://issues.apache.org/jira/browse/SOLR-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351534#comment-16351534 ] Grant Ingersoll commented on SOLR-11944: Draft patch w/ small snippet showing how to use `bin/post` to index geo json and WKT. > Add examples of WKT and GeoJSON Spatial indexing to spatial-search.adoc > --- > > Key: SOLR-11944 > URL: https://issues.apache.org/jira/browse/SOLR-11944 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll >Priority: Trivial > Attachments: SOLR-11944.patch > > > Took a bit of reading of the code to figure out how to index WKT and GeoJSON > files -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11944) Add examples of WKT and GeoJSON Spatial indexing to spatial-search.adoc
[ https://issues.apache.org/jira/browse/SOLR-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-11944: --- Attachment: SOLR-11944.patch > Add examples of WKT and GeoJSON Spatial indexing to spatial-search.adoc > --- > > Key: SOLR-11944 > URL: https://issues.apache.org/jira/browse/SOLR-11944 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll >Priority: Trivial > Attachments: SOLR-11944.patch > > > Took a bit of reading of the code to figure out how to index WKT and GeoJSON > files -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11944) Add examples of WKT and GeoJSON Spatial indexing to spatial-search.adoc
Grant Ingersoll created SOLR-11944: -- Summary: Add examples of WKT and GeoJSON Spatial indexing to spatial-search.adoc Key: SOLR-11944 URL: https://issues.apache.org/jira/browse/SOLR-11944 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Grant Ingersoll Assignee: Grant Ingersoll Took a bit of reading of the code to figure out how to index WKT and GeoJSON files -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10451) remove (almost) empty contrib/ltr folder from Solr binary release
[ https://issues.apache.org/jira/browse/SOLR-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006468#comment-16006468 ] Grant Ingersoll commented on SOLR-10451: Was just looking at and created SOLR-10667. I think we should ship the examples. I was surprised they weren't there when I built the package and thus none of the LTR docs really applied. > remove (almost) empty contrib/ltr folder from Solr binary release > - > > Key: SOLR-10451 > URL: https://issues.apache.org/jira/browse/SOLR-10451 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Christine Poerschke >Priority: Minor > Attachments: SOLR-10451.patch > > > As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the > {{contrib/ltr/lib}} folder. > So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr > binary release (it currently contains just a boilerplate {{README.txt}} file). > The {{ regex=".*\.jar" />}} line in > https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml > can also be removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10451) remove (almost) empty contrib/ltr folder from Solr binary release
[ https://issues.apache.org/jira/browse/SOLR-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006468#comment-16006468 ] Grant Ingersoll edited comment on SOLR-10451 at 5/11/17 2:06 PM: - Was just looking at and created SOLR-10667. I think we should ship the examples which I think means keeping this folder. I was surprised they weren't there when I built the package and thus none of the LTR docs really applied. was (Author: gsingers): Was just looking at and created SOLR-10667. I think we should ship the examples. I was surprised they weren't there when I built the package and thus none of the LTR docs really applied. > remove (almost) empty contrib/ltr folder from Solr binary release > - > > Key: SOLR-10451 > URL: https://issues.apache.org/jira/browse/SOLR-10451 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Christine Poerschke >Priority: Minor > Attachments: SOLR-10451.patch > > > As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the > {{contrib/ltr/lib}} folder. > So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr > binary release (it currently contains just a boilerplate {{README.txt}} file). > The {{ regex=".*\.jar" />}} line in > https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml > can also be removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10667) Solr packaging doesn't include Learn To Rank examples
Grant Ingersoll created SOLR-10667: -- Summary: Solr packaging doesn't include Learn To Rank examples Key: SOLR-10667 URL: https://issues.apache.org/jira/browse/SOLR-10667 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.5 Reporter: Grant Ingersoll I did an ant package on branch_6x and the resulting tarball doesn't have the LTR (learn to rank) examples included (things like the config.json, the model loading python script, etc.) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10041) Leader Initiated Recovery happening when the leader also fails to index the content
[ https://issues.apache.org/jira/browse/SOLR-10041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838856#comment-15838856 ] Grant Ingersoll commented on SOLR-10041: If the leader can't index the docs, it shouldn't cause the replicas to go into recovery. > Leader Initiated Recovery happening when the leader also fails to index the > content > --- > > Key: SOLR-10041 > URL: https://issues.apache.org/jira/browse/SOLR-10041 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Grant Ingersoll > Fix For: 6.3 > > > 1 shard, 3 replica setup. Documents are being fairly rapidly sent in for > indexing which are being rejected (due to a too long of a string field) by > the leader, which is then cascading outwards to put the replicas into Leader > Initiated Recovery, from which they never recover. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10041) Leader Initiated Recovery happening when the leader also fails to index the content
Grant Ingersoll created SOLR-10041: -- Summary: Leader Initiated Recovery happening when the leader also fails to index the content Key: SOLR-10041 URL: https://issues.apache.org/jira/browse/SOLR-10041 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Reporter: Grant Ingersoll Fix For: 6.3 1 shard, 3 replica setup. Documents are being fairly rapidly sent in for indexing which are being rejected (due to a too long of a string field) by the leader, which is then cascading outwards to put the replicas into Leader Initiated Recovery, from which they never recover. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
[ https://issues.apache.org/jira/browse/SOLR-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413719#comment-15413719 ] Grant Ingersoll commented on SOLR-6246: --- I've been hitting this as well. One suggestion that might minimize the impact: close the writer after build. In analyzing the method usages, we don't seem to call the inline/online "add/update" methods anywhere in the code, so there really isn't any reason to keep the writer open. I know in theory Lucene supports updating the suggesters, but we aren't using it. While closing the writer at the end of the build won't completely eliminate the problem (e.g. opening a new searcher while a build is underway), I think it could lower the likelihood. > Core fails to reload when AnalyzingInfixSuggester is used as a Suggester > > > Key: SOLR-6246 > URL: https://issues.apache.org/jira/browse/SOLR-6246 > Project: Solr > Issue Type: Sub-task > Components: SearchComponents - other >Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4 >Reporter: Varun Thacker > Attachments: SOLR-6246-test.patch, SOLR-6246-test.patch, > SOLR-6246.patch > > > LUCENE-5477 - added near-real-time suggest building to > AnalyzingInfixSuggester. One of the changes that went in was a writer is > persisted now to support real time updates via the add() and update() methods. > When we call Solr's reload command, a new instance of AnalyzingInfixSuggester > is created. When trying to create a new writer on the same Directory a lock > cannot be obtained and Solr fails to reload the core. > Also when AnalyzingInfixLookupFactory throws a RuntimeException we should > pass along the original message. > I am not sure what should be the approach to fix it. Should we have a > reloadHook where we close the writer? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359572#comment-15359572 ] Grant Ingersoll commented on LUCENE-7354: - OK, more detail: In my standalone server, I have a collection that has a single shard (I created it using bin/solr create_collection). The test has 2 shards, which then invokes RealTimeGetComponent.createSubRequests() which then adds an "ids" params, which is what then causes the the else clause cited above to get invoked. [~yo...@apache.org] can you provide some insight? (Most of the code was written by you) > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-7354-mlt-fix > > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359266#comment-15359266 ] Grant Ingersoll commented on LUCENE-7354: - I think the culprit is in RealTimeGetComponent.java, circa lines 278: {code} if (ids == null && allIds.length <= 1) { // if the doc was not found, then use a value of null. rsp.add("doc", docList.size() > 0 ? docList.get(0) : null); } else { docList.setNumFound(docList.size()); rsp.addResponse(docList); } {code} When debugging the test class (CloudMLTQParserTest), we end up in the else clause. When connecting to standalone via curl (e.g. http://localhost:8983/solr/mlt/select?indent=on&q={!mlt%20qf=resourcename}ID&wt=json)), we end up in the if clause. Still debugging what is causing ids and allIds to be set in the former case and not in the latter, as the query parameter looks almost identical. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) > Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-7354-mlt-fix > > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359212#comment-15359212 ] Grant Ingersoll commented on LUCENE-7354: - And also still seeing it on master, but the plot thickens: # When you debug via the test, it is as [~steve_rowe] says above # When you stand up solr (bin/solr) and issue an MLT query from curl (or the like), I see the Field objects > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-7354-mlt-fix > > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359145#comment-15359145 ] Grant Ingersoll commented on LUCENE-7354: - I'm certain this is occurring on 5.5.1 at a minimum. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) > Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-7354-mlt-fix > > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354907#comment-15354907 ] Grant Ingersoll commented on LUCENE-7354: - bq. I don't see this - when I run CloudMLTQParserTest without your patch, and I look at MoreLikeThis.retrieveTerms() where String.valueOf(fieldValue) is called (by pulling the value of that expression out into a variable and breaking there in the debugger), I only see the actual field values - no indexed stored et al. I'll check again, [~steve_rowe]. I was doing the same thing you describe. Could be a version issue. I am on Solr 5.5.1. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-7354-mlt-fix > > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15349635#comment-15349635 ] Grant Ingersoll edited comment on LUCENE-7354 at 6/25/16 12:45 PM: --- Mostly complete, but sharing early, as it's been a while since I've last patched Lucene/Solr. Not thrilled about the instanceof in CloudMLTQParser, but not much choice. Still need to wait on the full test suite to pass and to remove no commits and TODOs. was (Author: gsingers): Not complete, but sharing early, as it's been a while since I've last patched Lucene/Solr. Not thrilled about the instanceof in CloudMLTQParser, but not much choice. Still need to wait on the full test suite to pass and to remove no commits and TODOs. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) > Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-7354-mlt-fix > > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated LUCENE-7354: Attachment: LUCENE-7354-mlt-fix Not complete, but sharing early, as it's been a while since I've last patched Lucene/Solr. Not thrilled about the instanceof in CloudMLTQParser, but not much choice. Still need to wait on the full test suite to pass and to remove no commits and TODOs. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-7354-mlt-fix > > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15349595#comment-15349595 ] Grant Ingersoll commented on LUCENE-7354: - This is also a Solr issue. I'm not a big fan of the API for the like call in this particular case: {{code}}public Query like(Map> filteredDocument) throws IOException {{code}} is just asking for trouble, even if that saves a few operations in Solr. My proposal: # Change that signature, which is only used by Solr in CloudMLTQParser, to take Map>, thus forcing some type safety # Fix the retrieveTerms to check the fields line up. # Write some tests for the code path in question. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348848#comment-15348848 ] Grant Ingersoll edited comment on LUCENE-7354 at 6/24/16 11:15 PM: --- In looking at this code, it seems a bit more broken than I first thought. AFAICT, in retrieveTerms (circa line 760) we loop over the MLT configured fields, then we loop over the filteredDocument entries, but we don't actually check that the values in the filtered document are the ones configured on the MLT object. was (Author: gsingers): In looking at this code, it seems a bit more broken than I first thought. AFAICT, in retrieveTerms (circa line 79) we loop over the MLT configured fields, then we loop over the filteredDocument entries, but we don't actually check that the values in the filtered document are the ones configured on the MLT object. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348848#comment-15348848 ] Grant Ingersoll commented on LUCENE-7354: - In looking at this code, it seems a bit more broken than I first thought. AFAICT, in retrieveTerms (circa line 79) we loop over the MLT configured fields, then we loop over the filteredDocument entries, but we don't actually check that the values in the filtered document are the ones configured on the MLT object. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) > Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned LUCENE-7354: --- Assignee: Grant Ingersoll > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll >Priority: Minor > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
Grant Ingersoll created LUCENE-7354: --- Summary: MoreLikeThis incorrectly does toString on Field object Key: LUCENE-7354 URL: https://issues.apache.org/jira/browse/LUCENE-7354 Project: Lucene - Core Issue Type: Bug Affects Versions: 5.5.1, 6.0.1, master (7.0) Reporter: Grant Ingersoll Priority: Minor In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a Field object, we are incorrectly calling toString on the Field object, which puts the Field attributes (indexed, stored, et. al) into the String that is returned. I'll put up a patch/fix shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8942) Set "enableRemoteStreaming" to false in default configsets
Grant Ingersoll created SOLR-8942: - Summary: Set "enableRemoteStreaming" to false in default configsets Key: SOLR-8942 URL: https://issues.apache.org/jira/browse/SOLR-8942 Project: Solr Issue Type: Bug Reporter: Grant Ingersoll Priority: Minor Since enableRemoteStreaming is a known property that can cause security issues (see https://cwiki.apache.org/confluence/display/solr/Content+Streams), we should set it to false by default and/or remove it as a default configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7214) JSON Facet API
[ https://issues.apache.org/jira/browse/SOLR-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371443#comment-14371443 ] Grant Ingersoll commented on SOLR-7214: --- I should add, however, I think the "hanging of off" approach brings some interesting things to the table in terms of slicing and dicing things, but I admittedly haven't looked deeply at this new stuff. My main concern here isn't the implementation or any one approach, it's the we now have 2 approaches. That's not going to make for a good user experience. I would prefer we resolve the user experience before we commit and release this. > JSON Facet API > -- > > Key: SOLR-7214 > URL: https://issues.apache.org/jira/browse/SOLR-7214 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley > Attachments: SOLR-7214.patch > > > Overview is here: http://yonik.com/json-facet-api/ > The structured nature of nested sub-facets are more naturally expressed in a > nested structure like JSON rather than the flat structure that normal query > parameters provide. > Goals: > - First class JSON support > - Easier programmatic construction of complex nested facet commands > - Support a much more canonical response format that is easier for clients to > parse > - First class analytics support > - Support a cleaner way to do distributed faceting > - Support better integration with other search features -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7214) JSON Facet API
[ https://issues.apache.org/jira/browse/SOLR-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371421#comment-14371421 ] Grant Ingersoll commented on SOLR-7214: --- Yeah, I'm not a big fan of local params, so I'm all for a new approach to the API. We should work to consolidate and deprecate, while leveraging what we can under the hood. > JSON Facet API > -- > > Key: SOLR-7214 > URL: https://issues.apache.org/jira/browse/SOLR-7214 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley > Attachments: SOLR-7214.patch > > > Overview is here: http://yonik.com/json-facet-api/ > The structured nature of nested sub-facets are more naturally expressed in a > nested structure like JSON rather than the flat structure that normal query > parameters provide. > Goals: > - First class JSON support > - Easier programmatic construction of complex nested facet commands > - Support a much more canonical response format that is easier for clients to > parse > - First class analytics support > - Support a cleaner way to do distributed faceting > - Support better integration with other search features -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7214) JSON Facet API
[ https://issues.apache.org/jira/browse/SOLR-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364060#comment-14364060 ] Grant Ingersoll commented on SOLR-7214: --- How does this all fit with the work many have been doing on stats, facets, etc? Is there a way we can merge these features/functionality such that users don't have completely separate APIs for this stuff? e.g. SOLR-6348 and its children? > JSON Facet API > -- > > Key: SOLR-7214 > URL: https://issues.apache.org/jira/browse/SOLR-7214 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley > Attachments: SOLR-7214.patch > > > Overview is here: http://heliosearch.org/json-facet-api/ > The structured nature of nested sub-facets are more naturally expressed in a > nested structure like JSON rather than the flat structure that normal query > parameters provide. > Goals: > - First class JSON support > - Easier programmatic construction of complex nested facet commands > - Support a much more canonical response format that is easier for clients to > parse > - First class analytics support > - Support a cleaner way to do distributed faceting > - Support better integration with other search features -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Welcome Varun Thacker as Lucene/Solr committer
Hi All, Please join me in welcoming Varun Thacker as the latest committer on Lucene and Solr. Varun, tradition is for you to provide a brief bio about yourself. Welcome aboard! -Grant
[jira] [Created] (SOLR-6980) Collection deletion, creation and shared configsets
Grant Ingersoll created SOLR-6980: - Summary: Collection deletion, creation and shared configsets Key: SOLR-6980 URL: https://issues.apache.org/jira/browse/SOLR-6980 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll If a configset is not being shared and a collection is deleted, I think we should also delete the configset, or at least the copy of it for that collection. You can see the ill effects of this by doing: # create a data-driven schema collection # index some content to it, thus materializing an actual schema # delete the collection # create a new collection w/ the same name # observe that the new collection has the old materialized schema -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6965) Consider passing MIME-type info into field guessing capabilities
[ https://issues.apache.org/jira/browse/SOLR-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277390#comment-14277390 ] Grant Ingersoll commented on SOLR-6965: --- One of the main use cases for me is that CSV is often only single valued, so perhaps we would guess better there. See also SOLR-6979 > Consider passing MIME-type info into field guessing capabilities > > > Key: SOLR-6965 > URL: https://issues.apache.org/jira/browse/SOLR-6965 > Project: Solr > Issue Type: Improvement > Reporter: Grant Ingersoll > > In digging in on data-driven/field guessing/schemaless a bit more, my gut > instinct after staring at lots of different file types is that we should, if > possible, pass MIME type info through to the guessing mechanism so that we > can potentially make different choices for different types. For instance, > CSV is much more structured and can likely be smarter about data than XML or > PDF. Same goes for JSON. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6979) Smarter single-valued multi-valued handling in data-driven schema
Grant Ingersoll created SOLR-6979: - Summary: Smarter single-valued multi-valued handling in data-driven schema Key: SOLR-6979 URL: https://issues.apache.org/jira/browse/SOLR-6979 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll It would be nice if we could be smarter about single valued fields versus multi-valued when dealing w/ data-driven mode. For instance, we probably can assume single-valued until proven otherwise. May be some cases where a field is MV, but only ever has one value, too. I was talking to [~hossman_luc...@fucit.org] about this, too, and I believe he had some ideas that hopefully he can add here. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6977) Given a date/time, facet only by time
Grant Ingersoll created SOLR-6977: - Summary: Given a date/time, facet only by time Key: SOLR-6977 URL: https://issues.apache.org/jira/browse/SOLR-6977 Project: Solr Issue Type: Bug Components: faceting, SearchComponents - other Reporter: Grant Ingersoll Given a field that is indexed as date/time, it would be great if range faceting could facet only on date or only on time as an option. For instance, given a months worth of date, I'd like to be able to see what are the hotspots during throughout the day. Now, I could index a separate time field, but that seems redundant, as the data is already there. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6937) In schemaless mode, field names with spaces should be converted
[ https://issues.apache.org/jira/browse/SOLR-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275418#comment-14275418 ] Grant Ingersoll commented on SOLR-6937: --- +1 > In schemaless mode, field names with spaces should be converted > --- > > Key: SOLR-6937 > URL: https://issues.apache.org/jira/browse/SOLR-6937 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis > Reporter: Grant Ingersoll >Assignee: Noble Paul > Fix For: 5.0 > > Attachments: SOLR-6937.patch > > > Assuming spaces in field names are still bad, we should automatically convert > them to not have spaces. For instance, I indexed Citibike public data set > which has: > {quote} > "tripduration","starttime","stoptime","start station id","start station > name","start station latitude","start station longitude","end station > id","end station name","end station latitude","end station > longitude","bikeid","usertype","birth year","gender"{quote} > My vote would be to replace spaces w/ underscores. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6966) For Data Driven Schema, consider multi-word text fields to be text, not string field types
Grant Ingersoll created SOLR-6966: - Summary: For Data Driven Schema, consider multi-word text fields to be text, not string field types Key: SOLR-6966 URL: https://issues.apache.org/jira/browse/SOLR-6966 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll A tricky situation, for sure, but I suspect in data-driven mode, when field guessing, we should treat multi-word strings as text by default, not String, so that the user's first experience is they can search against that field. Alternatively, create a second field that is either the String version or the Text version. Even more advanced option: use pseudo-fields (like what we do for some spatial) and intelligently use one or the other depending on the context: e.g. faceting uses the one form, search uses the other. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6965) Consider passing MIME-type info into field guessing capabilities
[ https://issues.apache.org/jira/browse/SOLR-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14273616#comment-14273616 ] Grant Ingersoll commented on SOLR-6965: --- Sorry, "more structured" is the wrong wording here. I meant to say CSV is a bit more straightforward about guessing, I think. Obviously, with all of this stuff, there are exceptions. Just trying to hit the sweet spot of right most of the time for most situations, esp. the OOTB experience. > Consider passing MIME-type info into field guessing capabilities > > > Key: SOLR-6965 > URL: https://issues.apache.org/jira/browse/SOLR-6965 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll > > In digging in on data-driven/field guessing/schemaless a bit more, my gut > instinct after staring at lots of different file types is that we should, if > possible, pass MIME type info through to the guessing mechanism so that we > can potentially make different choices for different types. For instance, > CSV is much more structured and can likely be smarter about data than XML or > PDF. Same goes for JSON. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6965) Consider passing MIME-type info into field guessing capabilities
Grant Ingersoll created SOLR-6965: - Summary: Consider passing MIME-type info into field guessing capabilities Key: SOLR-6965 URL: https://issues.apache.org/jira/browse/SOLR-6965 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll In digging in on data-driven/field guessing/schemaless a bit more, my gut instinct after staring at lots of different file types is that we should, if possible, pass MIME type info through to the guessing mechanism so that we can potentially make different choices for different types. For instance, CSV is much more structured and can likely be smarter about data than XML or PDF. Same goes for JSON. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6952) Copying data-driven configsets by default is not helpful
[ https://issues.apache.org/jira/browse/SOLR-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272559#comment-14272559 ] Grant Ingersoll commented on SOLR-6952: --- To work around this, I tried this from a clean install: # bin/solr -cloud # bin/solr create_collectioin foo # bin/solr create_collection foo2 I then indexed the data to foo using the ints and then followed up and indexed to foo2 using the Strings and much to my dismay, I got the same error and have come to find out that the configset is being shared. This is bad, IMO. At a minimum, data-driven configsets should be copied from the default template and we should never modify the base template for a specific instance. Not sure on the other ones, but my gut says we should copy, not modify. > Copying data-driven configsets by default is not helpful > > > Key: SOLR-6952 > URL: https://issues.apache.org/jira/browse/SOLR-6952 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 5.0 > Reporter: Grant Ingersoll > Fix For: 5.0 > > > When creating collections (I'm using the bin/solr scripts), I don't think we > should automatically copy configsets, especially when running in "getting > started mode" or data driven mode. > I did the following: > {code} > bin/solr create_collection -n foo > bin/post foo some_data.csv > {code} > I then created a second collection with the intention of sending in the same > data, but this time run through a python script that changed a value from an > int to a string (since it was an enumerated type) and was surprised to see > that I got: > {quote} > Caused by: java.lang.NumberFormatException: For input string: "NA" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.lang.Long.parseLong(Long.java:441) > {quote} > for my new version of the data that passes in a string instead of an int, as > this new collection had only seen strings for that field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6952) Copying data-driven configsets by default is not helpful
[ https://issues.apache.org/jira/browse/SOLR-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-6952: -- Component/s: Schema and Analysis Affects Version/s: 5.0 Fix Version/s: 5.0 > Copying data-driven configsets by default is not helpful > > > Key: SOLR-6952 > URL: https://issues.apache.org/jira/browse/SOLR-6952 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 5.0 > Reporter: Grant Ingersoll > Fix For: 5.0 > > > When creating collections (I'm using the bin/solr scripts), I don't think we > should automatically copy configsets, especially when running in "getting > started mode" or data driven mode. > I did the following: > {code} > bin/solr create_collection -n foo > bin/post foo some_data.csv > {code} > I then created a second collection with the intention of sending in the same > data, but this time run through a python script that changed a value from an > int to a string (since it was an enumerated type) and was surprised to see > that I got: > {quote} > Caused by: java.lang.NumberFormatException: For input string: "NA" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.lang.Long.parseLong(Long.java:441) > {quote} > for my new version of the data that passes in a string instead of an int, as > this new collection had only seen strings for that field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6952) Copying data-driven configsets by default is not helpful
Grant Ingersoll created SOLR-6952: - Summary: Copying data-driven configsets by default is not helpful Key: SOLR-6952 URL: https://issues.apache.org/jira/browse/SOLR-6952 Project: Solr Issue Type: Bug Reporter: Grant Ingersoll When creating collections (I'm using the bin/solr scripts), I don't think we should automatically copy configsets, especially when running in "getting started mode" or data driven mode. I did the following: {code} bin/solr create_collection -n foo bin/post foo some_data.csv {code} I then created a second collection with the intention of sending in the same data, but this time run through a python script that changed a value from an int to a string (since it was an enumerated type) and was surprised to see that I got: {quote} Caused by: java.lang.NumberFormatException: For input string: "NA" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:441) {quote} for my new version of the data that passes in a string instead of an int, as this new collection had only seen strings for that field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6913) audit & cleanup "schema" in data_driven_schema_configs
[ https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14271806#comment-14271806 ] Grant Ingersoll commented on SOLR-6913: --- Awesome, thanks Steve! > audit & cleanup "schema" in data_driven_schema_configs > -- > > Key: SOLR-6913 > URL: https://issues.apache.org/jira/browse/SOLR-6913 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Blocker > Fix For: 5.0, Trunk > > Attachments: SOLR-6913-trim-schema.patch, > SOLR-6913-trim-schema.patch, SOLR-6913.patch > > > the data_driven_schema_configs configset has some issues that should be > reviewed carefully & cleaned up... > * currentkly includes a schema.xml file: > ** this was previously pat of the old example to show the automatic > "bootstraping" of schema.xml -> managed-schema, but at this point it's just > kind of confusing > ** we should just rename this to "managed-schema" in svn - the ref guide > explains the bootstraping > * the effective schema as it currently stands includes a bunch of copyFields > & dynamicFields that are taken wholesale from the techproducts example > ** some of these might make sense to keep in a general example (ie: "\*_txt") > but in general they should all be reviewed. > ** a bunch of this cruft is actually commented out already, but anything we > don't want to keep should be removed to eliminate confusion > * SOLR-6471 added an explicit "_text" field as the default and made it a > copyField catchall (ie: "\*") > ** the ref guide schema API example responses need to reflect the existence > of this field: > https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode > ** we should draw heavy attention to this field+copyField -- both with a "/!\ > NOTE" in the refguide and call it out in solrconfig.xml & "managed-schema" > file comments since people who start with these configs may be suprised and > wind up with a very bloated index -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6913) audit & cleanup "schema" in data_driven_schema_configs
[ https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14271499#comment-14271499 ] Grant Ingersoll commented on SOLR-6913: --- IOW, it's not about schemaless, it's about schema-later > audit & cleanup "schema" in data_driven_schema_configs > -- > > Key: SOLR-6913 > URL: https://issues.apache.org/jira/browse/SOLR-6913 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Blocker > Fix For: 5.0, Trunk > > Attachments: SOLR-6913-trim-schema.patch, > SOLR-6913-trim-schema.patch, SOLR-6913.patch > > > the data_driven_schema_configs configset has some issues that should be > reviewed carefully & cleaned up... > * currentkly includes a schema.xml file: > ** this was previously pat of the old example to show the automatic > "bootstraping" of schema.xml -> managed-schema, but at this point it's just > kind of confusing > ** we should just rename this to "managed-schema" in svn - the ref guide > explains the bootstraping > * the effective schema as it currently stands includes a bunch of copyFields > & dynamicFields that are taken wholesale from the techproducts example > ** some of these might make sense to keep in a general example (ie: "\*_txt") > but in general they should all be reviewed. > ** a bunch of this cruft is actually commented out already, but anything we > don't want to keep should be removed to eliminate confusion > * SOLR-6471 added an explicit "_text" field as the default and made it a > copyField catchall (ie: "\*") > ** the ref guide schema API example responses need to reflect the existence > of this field: > https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode > ** we should draw heavy attention to this field+copyField -- both with a "/!\ > NOTE" in the refguide and call it out in solrconfig.xml & "managed-schema" > file comments since people who start with these configs may be suprised and > wind up with a very bloated index -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6913) audit & cleanup "schema" in data_driven_schema_configs
[ https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14271487#comment-14271487 ] Grant Ingersoll commented on SOLR-6913: --- bq. My thinking was that the schemaless example should be minimal. In particular, if we don't have a way for field types to be used (via (dynamic)field definitions or field guessing), why include them? If the user can add fields, they can add field types too. The main issue is that OOTB, this is the default and it thus leaves us pretty underpowered for an OOTB experience. Those Field Types have been in Solr for a long time and I think they hold up reasonably well, so I would vote for putting them back in. I think the big difference is, Solr experts come at the situation from edit schema/config first. New users come at data stores as let me manipulate my data first and then harden it later. > audit & cleanup "schema" in data_driven_schema_configs > -- > > Key: SOLR-6913 > URL: https://issues.apache.org/jira/browse/SOLR-6913 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Blocker > Fix For: 5.0, Trunk > > Attachments: SOLR-6913-trim-schema.patch, > SOLR-6913-trim-schema.patch, SOLR-6913.patch > > > the data_driven_schema_configs configset has some issues that should be > reviewed carefully & cleaned up... > * currentkly includes a schema.xml file: > ** this was previously pat of the old example to show the automatic > "bootstraping" of schema.xml -> managed-schema, but at this point it's just > kind of confusing > ** we should just rename this to "managed-schema" in svn - the ref guide > explains the bootstraping > * the effective schema as it currently stands includes a bunch of copyFields > & dynamicFields that are taken wholesale from the techproducts example > ** some of these might make sense to keep in a general example (ie: "\*_txt") > but in general they should all be reviewed. > ** a bunch of this cruft is actually commented out already, but anything we > don't want to keep should be removed to eliminate confusion > * SOLR-6471 added an explicit "_text" field as the default and made it a > copyField catchall (ie: "\*") > ** the ref guide schema API example responses need to reflect the existence > of this field: > https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode > ** we should draw heavy attention to this field+copyField -- both with a "/!\ > NOTE" in the refguide and call it out in solrconfig.xml & "managed-schema" > file comments since people who start with these configs may be suprised and > wind up with a very bloated index -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6940) Query UI in admin should support other facet options
Grant Ingersoll created SOLR-6940: - Summary: Query UI in admin should support other facet options Key: SOLR-6940 URL: https://issues.apache.org/jira/browse/SOLR-6940 Project: Solr Issue Type: Improvement Components: web gui Reporter: Grant Ingersoll As of right now in the Admin Query UI, you can only easily provide facet options for field, query and prefix. It would be nice to have easy to use options for pivots, ranges, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6913) audit & cleanup "schema" in data_driven_schema_configs
[ https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270989#comment-14270989 ] Grant Ingersoll commented on SOLR-6913: --- I'd vote for returning: # geo related # currency # Language support Indifferent on the rest. > audit & cleanup "schema" in data_driven_schema_configs > -- > > Key: SOLR-6913 > URL: https://issues.apache.org/jira/browse/SOLR-6913 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Blocker > Fix For: 5.0, Trunk > > Attachments: SOLR-6913-trim-schema.patch, > SOLR-6913-trim-schema.patch, SOLR-6913.patch > > > the data_driven_schema_configs configset has some issues that should be > reviewed carefully & cleaned up... > * currentkly includes a schema.xml file: > ** this was previously pat of the old example to show the automatic > "bootstraping" of schema.xml -> managed-schema, but at this point it's just > kind of confusing > ** we should just rename this to "managed-schema" in svn - the ref guide > explains the bootstraping > * the effective schema as it currently stands includes a bunch of copyFields > & dynamicFields that are taken wholesale from the techproducts example > ** some of these might make sense to keep in a general example (ie: "\*_txt") > but in general they should all be reviewed. > ** a bunch of this cruft is actually commented out already, but anything we > don't want to keep should be removed to eliminate confusion > * SOLR-6471 added an explicit "_text" field as the default and made it a > copyField catchall (ie: "\*") > ** the ref guide schema API example responses need to reflect the existence > of this field: > https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode > ** we should draw heavy attention to this field+copyField -- both with a "/!\ > NOTE" in the refguide and call it out in solrconfig.xml & "managed-schema" > file comments since people who start with these configs may be suprised and > wind up with a very bloated index -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6913) audit & cleanup "schema" in data_driven_schema_configs
[ https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270981#comment-14270981 ] Grant Ingersoll commented on SOLR-6913: --- I think the regular workflow for exploring new datasets is to just start throwing it at Solr and then to tweak the data, not tweak the schema. Data first, schema second. So, for instance, I'm working on this citibike data. My first step is to index it w/ no schema whatsoever. I then iterate by writing a little python to index some of the columns as spatial. What I don't do is go muck w/ the schema, hence the name data-driven. > audit & cleanup "schema" in data_driven_schema_configs > -- > > Key: SOLR-6913 > URL: https://issues.apache.org/jira/browse/SOLR-6913 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Blocker > Fix For: 5.0, Trunk > > Attachments: SOLR-6913-trim-schema.patch, > SOLR-6913-trim-schema.patch, SOLR-6913.patch > > > the data_driven_schema_configs configset has some issues that should be > reviewed carefully & cleaned up... > * currentkly includes a schema.xml file: > ** this was previously pat of the old example to show the automatic > "bootstraping" of schema.xml -> managed-schema, but at this point it's just > kind of confusing > ** we should just rename this to "managed-schema" in svn - the ref guide > explains the bootstraping > * the effective schema as it currently stands includes a bunch of copyFields > & dynamicFields that are taken wholesale from the techproducts example > ** some of these might make sense to keep in a general example (ie: "\*_txt") > but in general they should all be reviewed. > ** a bunch of this cruft is actually commented out already, but anything we > don't want to keep should be removed to eliminate confusion > * SOLR-6471 added an explicit "_text" field as the default and made it a > copyField catchall (ie: "\*") > ** the ref guide schema API example responses need to reflect the existence > of this field: > https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode > ** we should draw heavy attention to this field+copyField -- both with a "/!\ > NOTE" in the refguide and call it out in solrconfig.xml & "managed-schema" > file comments since people who start with these configs may be suprised and > wind up with a very bloated index -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6913) audit & cleanup "schema" in data_driven_schema_configs
[ https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270978#comment-14270978 ] Grant Ingersoll commented on SOLR-6913: --- What's the reasoning behind removing so many of the field types? > audit & cleanup "schema" in data_driven_schema_configs > -- > > Key: SOLR-6913 > URL: https://issues.apache.org/jira/browse/SOLR-6913 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Blocker > Fix For: 5.0, Trunk > > Attachments: SOLR-6913-trim-schema.patch, > SOLR-6913-trim-schema.patch, SOLR-6913.patch > > > the data_driven_schema_configs configset has some issues that should be > reviewed carefully & cleaned up... > * currentkly includes a schema.xml file: > ** this was previously pat of the old example to show the automatic > "bootstraping" of schema.xml -> managed-schema, but at this point it's just > kind of confusing > ** we should just rename this to "managed-schema" in svn - the ref guide > explains the bootstraping > * the effective schema as it currently stands includes a bunch of copyFields > & dynamicFields that are taken wholesale from the techproducts example > ** some of these might make sense to keep in a general example (ie: "\*_txt") > but in general they should all be reviewed. > ** a bunch of this cruft is actually commented out already, but anything we > don't want to keep should be removed to eliminate confusion > * SOLR-6471 added an explicit "_text" field as the default and made it a > copyField catchall (ie: "\*") > ** the ref guide schema API example responses need to reflect the existence > of this field: > https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode > ** we should draw heavy attention to this field+copyField -- both with a "/!\ > NOTE" in the refguide and call it out in solrconfig.xml & "managed-schema" > file comments since people who start with these configs may be suprised and > wind up with a very bloated index -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6764) Can't index exampledocs/*.xml into collection based on the data_driven_schema_configs configset
[ https://issues.apache.org/jira/browse/SOLR-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270974#comment-14270974 ] Grant Ingersoll commented on SOLR-6764: --- Path works for me. Didn't do exhaustive testing, but w/ the data set I had I got this every time. Now I don't. > Can't index exampledocs/*.xml into collection based on the > data_driven_schema_configs configset > --- > > Key: SOLR-6764 > URL: https://issues.apache.org/jira/browse/SOLR-6764 > Project: Solr > Issue Type: Bug >Reporter: Timothy Potter >Assignee: Timothy Potter > Attachments: SOLR-6764.patch > > > This is exactly what we don't want ;-) Fire up a collection that uses the > data_driven_schema_configs (such as by doing: bin/solr -e cloud -noprompt) > and then try to index our example docs using: > $ java -Durl=http://localhost:8983/solr/gettingstarted/update -jar post.jar > *.xml > Here goes the spew ... > SimplePostTool version 1.5 > Posting files to base url http://localhost:8983/solr/gettingstarted/update > using content-type application/xml.. > POSTing file gb18030-example.xml > POSTing file hd.xml > SimplePostTool: WARNING: Solr returned an error #500 (Server Error) for url: > http://localhost:8983/solr/gettingstarted/update > SimplePostTool: WARNING: Response: > > 500 name="QTime">19Server Error > request: > http://192.168.1.2:8983/solr/gettingstarted_shard2_replica2/update?update.chain=add-unknown-fields-to-the-schema&update.distrib=TOLEADER&distrib.from=http%3A%2F%2F192.168.1.2%3A8983%2Fsolr%2Fgettingstarted_shard1_replica2%2F&wt=javabin&version=2 name="trace">org.apache.solr.common.SolrException: Server Error > request: > http://192.168.1.2:8983/solr/gettingstarted_shard2_replica2/update?update.chain=add-unknown-fields-to-the-schema&update.distrib=TOLEADER&distrib.from=http%3A%2F%2F192.168.1.2%3A8983%2Fsolr%2Fgettingstarted_shard1_replica2%2F&wt=javabin&version=2 > at > org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:241) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > 500 > > SimplePostTool: WARNING: IOException while reading response: > java.io.IOException: Server returned HTTP response code: 500 for URL: > http://localhost:8983/solr/gettingstarted/update > POSTing file ipod_other.xml > SimplePostTool: WARNING: Solr returned an error #400 (Bad Request) for url: > http://localhost:8983/solr/gettingstarted/update > SimplePostTool: WARNING: Response: > > 400 name="QTime">630ERROR: > [doc=IW-02] Error adding field 'price'='11.50' msg=For input string: > "11.50"400 > > SimplePostTool: WARNING: IOException while reading response: > java.io.IOException: Server returned HTTP response code: 400 for URL: > http://localhost:8983/solr/gettingstarted/update > POSTing file ipod_video.xml > SimplePostTool: WARNING: Solr returned an error #400 (Bad Request) for url: > http://localhost:8983/solr/gettingstarted/update > SimplePostTool: WARNING: Response: > > 400 name="QTime">5ERROR: > [doc=MA147LL/A] Error adding field 'weight'='5.5' msg=For input string: > "5.5"400 > > SimplePostTool: WARNING: IOException while reading response: > java.io.IOException: Server returned HTTP response code: 400 for URL: > http://localhost:8983/solr/gettingstarted/update > POSTing file manufacturers.xml > SimplePostTool: WARNING: Solr returned an error #500 (Server Error) for url: > http://localhost:8983/solr/gettingstarted/update > SimplePostTool: WARNING: Response: > > 500 name="QTime">2Exception writing > document id adata to the index; possible analysis error. name="trace">org.apache.solr.common.SolrException: Exception writing document > id adata to the index; possible analysis error. > at > org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:168) > at > org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69) > at > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) > at > org.apache.solr.update.processo
[jira] [Updated] (SOLR-6937) In schemaless mode, field names with spaces should be converted
[ https://issues.apache.org/jira/browse/SOLR-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-6937: -- Component/s: Schema and Analysis Fix Version/s: 5.0 > In schemaless mode, field names with spaces should be converted > --- > > Key: SOLR-6937 > URL: https://issues.apache.org/jira/browse/SOLR-6937 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis > Reporter: Grant Ingersoll > Fix For: 5.0 > > > Assuming spaces in field names are still bad, we should automatically convert > them to not have spaces. For instance, I indexed Citibike public data set > which has: > {quote} > "tripduration","starttime","stoptime","start station id","start station > name","start station latitude","start station longitude","end station > id","end station name","end station latitude","end station > longitude","bikeid","usertype","birth year","gender"{quote} > My vote would be to replace spaces w/ underscores. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6933) bin/solr script should just have a single create action that creates a core or collection depending on the mode solr is running in
[ https://issues.apache.org/jira/browse/SOLR-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270479#comment-14270479 ] Grant Ingersoll commented on SOLR-6933: --- bq. and instead adding a new "create" that delegates to them as needed. +1 bq. First, what does the usage (bin/solr create -help) say? Options like -shards, -maxShardsPerNode, -replicationFactor don't apply when creating a core. If we are just delegating, than can we delegate to the underlying help too? bq. I think the script should error out and tell the user that option is only when running in cloud mode. +1 bq. So if we think there's real benefit to having a "create" alias +1 > bin/solr script should just have a single create action that creates a core > or collection depending on the mode solr is running in > -- > > Key: SOLR-6933 > URL: https://issues.apache.org/jira/browse/SOLR-6933 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Timothy Potter >Assignee: Timothy Potter > > instead of create_core and create_collection, just have create that creates a > core or a collection based on which mode Solr is running in. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6937) In schemaless mode, field names with spaces should be converted
Grant Ingersoll created SOLR-6937: - Summary: In schemaless mode, field names with spaces should be converted Key: SOLR-6937 URL: https://issues.apache.org/jira/browse/SOLR-6937 Project: Solr Issue Type: Bug Reporter: Grant Ingersoll Assuming spaces in field names are still bad, we should automatically convert them to not have spaces. For instance, I indexed Citibike public data set which has: {quote} "tripduration","starttime","stoptime","start station id","start station name","start station latitude","start station longitude","end station id","end station name","end station latitude","end station longitude","bikeid","usertype","birth year","gender"{quote} My vote would be to replace spaces w/ underscores. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6764) Can't index exampledocs/*.xml into collection based on the data_driven_schema_configs configset
[ https://issues.apache.org/jira/browse/SOLR-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270035#comment-14270035 ] Grant Ingersoll commented on SOLR-6764: --- I'm seeing similar when I try to index the Citibike data out of the box: http://www.citibikenyc.com/system-data I did: {code} bin/solr start -cloud bin/solr create_collection -n citi bin/post citi ~/projects/content/citi-bike/2013-07-CitiBiketripdata.csv {code} Seeing: {quote} ERROR - 2015-01-08 20:47:00.973; org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: Exception writing document id 662e0607-6fd2-4ecc-91f1-40384cf232e3 to the index; possible analysis error. at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:171) at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:328) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:931) at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1085) at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:697) at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:94) at org.apache.solr.handler.loader.CSVLoaderBase.doAdd(CSVLoaderBase.java:395) at org.apache.solr.handler.loader.SingleThreadedCSVLoader.addDoc(CSVLoader.java:44) at org.apache.solr.handler.loader.CSVLoaderBase.load(CSVLoaderBase.java:364) at org.apache.solr.handler.loader.CSVLoader.load(CSVLoader.java:31) at org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:103) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2005) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:779) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:414) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:201) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) at org.eclipse.jetty.server.session.SessionHandle
[jira] [Commented] (SOLR-6900) bin/post improvements needed
[ https://issues.apache.org/jira/browse/SOLR-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270021#comment-14270021 ] Grant Ingersoll commented on SOLR-6900: --- I tried: {code} bin/post citi "/foo/projects/content/citi-bike/2013-07 - Citi Bike trip data.csv" bin/post citi "/foo/projects/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ bin/post citi /foo/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ data.csv {code} > bin/post improvements needed > > > Key: SOLR-6900 > URL: https://issues.apache.org/jira/browse/SOLR-6900 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0, Trunk >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: 5.0, Trunk > > > * Fix glob patterns. They don't work as expected: bin/post collection1 > \*.xml expands \*.xml such that the script gets all the file names as > parameters not just literally "\*.xml" > * Add error handling to check that the collection exists > * Create Windows version -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6900) bin/post improvements needed
[ https://issues.apache.org/jira/browse/SOLR-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270021#comment-14270021 ] Grant Ingersoll edited comment on SOLR-6900 at 1/8/15 8:45 PM: --- I tried: {code} bin/post citi "/foo/projects/content/citi-bike/2013-07 - Citi Bike trip data.csv" bin/post citi "/foo/projects/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ bin/post citi /foo/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ data.csv {code} All failed w/ errors in parsing spaces. was (Author: gsingers): I tried: {code} bin/post citi "/foo/projects/content/citi-bike/2013-07 - Citi Bike trip data.csv" bin/post citi "/foo/projects/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ bin/post citi /foo/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ data.csv {code} > bin/post improvements needed > > > Key: SOLR-6900 > URL: https://issues.apache.org/jira/browse/SOLR-6900 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0, Trunk >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: 5.0, Trunk > > > * Fix glob patterns. They don't work as expected: bin/post collection1 > \*.xml expands \*.xml such that the script gets all the file names as > parameters not just literally "\*.xml" > * Add error handling to check that the collection exists > * Create Windows version -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory
[ https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14269740#comment-14269740 ] Grant Ingersoll commented on SOLR-3619: --- My pref would be: bin/solr create and we handle the cloud logic under the scenes. > 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: 5.0, Trunk > > Attachments: SOLR-3619.patch, SOLR-3619.patch, SOLR-3619.patch, > managed-schema, server-name-layout.png, solrconfig.xml > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory
[ https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14269733#comment-14269733 ] Grant Ingersoll commented on SOLR-3619: --- First off, love the new stuff! Coming a little late to the party, but just now finally checking this out. So, I built the distro, copied it to a new directory and unpacked it. I then went to the README which is the first thing I do for any "new" software (as I suspect most devs do) and here's what I see: {quote} This will launch a Solr server in the background of your shell, bound to port 8983. After starting Solr, you can create a new core for indexing your data by doing: bin/solr create_core -n {quote} and then a few lines later: {quote} After starting Solr in cloud mode, you can create a new collection for indexing your data by doing: bin/solr create_collection -n {quote} You've already lost me (well, not me, literally, but noobs, I'm sure). What the heck is the diff between a collection and a core and why should I care so early on? Why should I have to know that distinction at this stage of the game? I get that it relates to the Collections API and cloud mode, but I'm a new user and that distinction, in my estimation, is at least a day or two away (and hopefully is resolved at some point and becomes a non-issue) at which time it can be explained via the Docs in the ref guide. Just my 2 cents. > 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: 5.0, Trunk > > Attachments: SOLR-3619.patch, SOLR-3619.patch, SOLR-3619.patch, > managed-schema, server-name-layout.png, solrconfig.xml > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14203423#comment-14203423 ] Grant Ingersoll commented on SOLR-6058: --- Getting really close. I think the main thing left is the tutorial and proof-reading. As I've said earlier, I'd like to finish up and go live on tomorrow or Monday. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14200071#comment-14200071 ] Grant Ingersoll commented on SOLR-6058: --- [~sbower] Thanks! > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198588#comment-14198588 ] Grant Ingersoll commented on SOLR-6058: --- OK, this is getting really close to done. I think we just have some issues left on the Detailed Features section and the tutorial for content. After that, a full read through, grammar, spelling, etc. and we are good to go. We also still need to figure out the links thing due to offsets on the main page (and other places, I presume) Pending those things completing, I intend to merge this to trunk and push this live over the weekend, as this has been baking for some time now and is very close to ready to go. We can always improve later. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198548#comment-14198548 ] Grant Ingersoll commented on SOLR-6058: --- [~sbower] any luck on the logo permission? We'd like to go live by this weekend. At some level, the fact that Bloomberg is a Solr user is a factual statement and doesn't require permission since it is public knowledge based off presentations, etc., but I do understand the use of a logo may not be the equivalent to that, so I'd rather make sure Bloomberg is OK with it. I can remove it if we can't get permission in time or we can switch to a factual statement. FWIW, I'd love to put highlight Bloomberg as a Solr case study somewhere on the Solr site if you are willing to do so. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198475#comment-14198475 ] Grant Ingersoll commented on SOLR-6058: --- OK, talked w/ [~steve_rowe] and he figured out that this issue is tied to the offset class that is on the section here. It causes the hover view part of it to be clipped at the bottom. This is most exacerbated when you zoom out (50%-75% or original) This happens across Chrome, Safari and FF. [~FranLukesh] > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198290#comment-14198290 ] Grant Ingersoll commented on SOLR-6058: --- Starting to think the issue is the interaction with the div and the a tag on those links. It seems there is some oddities in how it is handling the nested div in the a tag. Hard to explain, but if you hover the mouse in the correct place, you'll see the a tag can be selected to the left of the main box area. You can see this further by putting some junk text in the a tag, but outside of the nested div, as in: {code} Foo Features Hundreds of features make Solr incredibly versatile. Learn More {code} > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198248#comment-14198248 ] Grant Ingersoll commented on SOLR-6058: --- Hmm: http://stackoverflow.com/questions/6393827/can-i-nest-a-button-element-inside-an-a-using-html5 may be the cause? > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198232#comment-14198232 ] Grant Ingersoll commented on SOLR-6058: --- More fun: if you zoom out w/ Dev Tools on, than you can incur the same bad behavior. Seems like there has to be an open tag or something. I did a validation of the page and it seems fine. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198230#comment-14198230 ] Grant Ingersoll commented on SOLR-6058: --- More oddities: If you zoom in (to like 125%) using Chrome on these links (apple-+ on Mac), then they work just fine. I've also notice that if you go slowly from the bottom of the element, you can get it to highlight. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198181#comment-14198181 ] Grant Ingersoll commented on SOLR-6058: --- The really odd thing, is the Getting Started section further below is more or less the same and it works fine. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198153#comment-14198153 ] Grant Ingersoll commented on SOLR-6058: --- For those watching this issue, we've noticed some weird behavior with certain browsers and I was wondering if others could report if they see it to. On the main page (solr-index.html), under the "Learn More About Solr" section, the links to "learn more" about Features, Resources, etc. don't always work when you hover over the box. For instance, on Chrome when I look at http://lucene.lukesh.com/solr/, I can't click on any of those items. Strangely enough, if I open the Chrome Developer Tools or view the page source, I can. Additionally, when I look at my own local copy, I don't have any trouble. Links also seem to work in Firefox, but don't always work in Safari. I know [~steve_rowe] has said he has had similar failures as well. Can people report back here whether they are seeing it or whether it is perhaps some sort of caching bug, perhaps? > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6081) Hook in Videos, Books, Reference work
[ https://issues.apache.org/jira/browse/SOLR-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-6081. --- Resolution: Fixed > Hook in Videos, Books, Reference work > - > > Key: SOLR-6081 > URL: https://issues.apache.org/jira/browse/SOLR-6081 > Project: Solr > Issue Type: Sub-task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > > There is a ton of great content available on Solr in the interwebs, let's > make it easy to highlight this content so users know their is a large > community ready to assist. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6081) Hook in Videos, Books, Reference work
[ https://issues.apache.org/jira/browse/SOLR-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-6081: - Assignee: Grant Ingersoll > Hook in Videos, Books, Reference work > - > > Key: SOLR-6081 > URL: https://issues.apache.org/jira/browse/SOLR-6081 > Project: Solr > Issue Type: Sub-task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > > There is a ton of great content available on Solr in the interwebs, let's > make it easy to highlight this content so users know their is a large > community ready to assist. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193239#comment-14193239 ] Grant Ingersoll commented on SOLR-6058: --- Made a bunch of progress this AM: # Features page first draft is complete. TODO: add some more spice to the detailed features section with images # Fixed the download buttons # Cleaned up some of the resources # Fixed a bunch of links # Added Google Analytics to the footer # Cleaned up the footer with proper links # Other things I forgot to mention I'm really hoping we can push this live by the end of the next week (a week from today) as most of the core content is in place now with the exception of the tutorials. Naturally, we also need to do a run through of links, spelling errors, grammar and more. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, > Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, > Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193115#comment-14193115 ] Grant Ingersoll commented on SOLR-6058: --- Not quite sure what to do w/ the Documentation section on the Resources page. Currently, we link to the docs that ship with the latest release (http://lucene.apache.org/solr/4_10_1/index.html) which is kind of clunky, albeit accurate. I like what Fran did for organizing it, but it will suffer from a versioning problem. Personally, I'd prefer to just link the Ref Guide and forget linking anything else. For now, I'm just going to maintain what we have (link to latest release) > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, > Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, > Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193097#comment-14193097 ] Grant Ingersoll commented on SOLR-6058: --- Made some progress on the resources page. I'm going to drop the screenshots section, as it will likely be out of date and annoying to maintain. I would love if someone knew how to bring in a few key videos, presentations, etc. and rotate between them so that we can have some clickable content there. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, > Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, > Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193091#comment-14193091 ] Grant Ingersoll commented on SOLR-6058: --- bq. For Bloomberg, and I suspect other companies as well, will need to have the use of our logo approved from a trademark usage perspective. We're happy to do this we just need go through the process. Steven, that would be great if you could see that through! > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, > Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, > Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184057#comment-14184057 ] Grant Ingersoll commented on SOLR-6058: --- bq. From the Solr front page (solr/index.html), under the book cover images, the "Learn More" button links to solr/books.html, which is currently empty. The solr/resources.html page has a books section - should the button in question link there instead? Should there also be a separate books page sharing the same content? I think we should just put it on the resources page and link appropriately. Would be nice to have the book covers on those pages. bq. There's a missing logo file: solr/assets/images/logo-eharmony.png, linked from templates/solr-index.html. I missed that one. Will add. bq. On the solr/resources.html page, the links along the top (Tutorial, Release, Documentation, Books, Links, Screenshots) are supposed to go to sections on the same page, e.g. Tutorial->#tutorial, but instead when you click on one of them, the URL is appended with a hash mark, slash, then the fragment id, e.g. #/tutorial, and then the browser doesn't go where it's supposed to. I don't see anything in the generated HTML that would cause this - the fragment URLs in the links on the generated HTML don't include the slash. I've seen this on lukesh.com, as well as a locally built version of the site, and both via Safari on OS X and Firefox on Windows 7. I can look > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, > Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, > Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, > Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178392#comment-14178392 ] Grant Ingersoll commented on SOLR-6058: --- My progress for today: # Added some powered by icons on the front page (still need to be styled) # Templatized the version annotation at the top of the landing so we can change the latest version number in just one place # Worked a bunch on the features page (features.mdtext). Left off at the "Detailed Features" section. [~FranLukesh], note, I put in some TODO placeholders on some of the icons in the second section as they are repetitive with the first section. All in all, I'm really liking the look and feel. I'd hope we can get this live in the next two weeks or so. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, > Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, > Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, > Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178348#comment-14178348 ] Grant Ingersoll commented on SOLR-6058: --- [~elyograg] Good catch, I will update. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, > Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, > Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, > Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178346#comment-14178346 ] Grant Ingersoll commented on SOLR-6058: --- [~FranLukesh] One of the things I'd like to figure out, is how to properly link back to the Lucene sites, as the nav is a bit weird. If a user is on lucene.a.o and nav's to solr, all of the tabs disappear, which is probably somewhat counter-intuitive to the user. I don't think the tabs fit with the new design, but at the same time, it would be good to somehow make it clear how to get back. Also, I uploaded some logos from the Solr Public Servers page. I could use some help making them look right. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, > Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, > Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, > Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178261#comment-14178261 ] Grant Ingersoll commented on SOLR-6058: --- OK, I've committed Fran's original patch on the branch. [~FranLukesh] any chance you can script your original server to automatically apply updates on from that branch so others can see the changes we make? Otherwise, I can do the same. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, > Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, > Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, > Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177177#comment-14177177 ] Grant Ingersoll commented on SOLR-6058: --- I've started a branch for this: https://svn.apache.org/repos/asf/lucene/cms/branches/solr_6058 since there will be a lot of content to work on and patches will quickly get clumsy. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, > Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, > Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, > Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175383#comment-14175383 ] Grant Ingersoll commented on SOLR-6058: --- Looks great, Fran! I should be able to find some time to help on content. Hopefully others can pitch in, too. I have the CMS running locally (finally) and can help others if needed. https://github.com/waylan/Python-Markdown/issues/357 may help for anyone that runs into trouble w/ the Python Markdown process. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, > Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, > Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, > Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
On Sep 19, 2014, at 10:23 AM, Yonik Seeley wrote: > On Fri, Sep 19, 2014 at 7:14 AM, Grant Ingersoll wrote: >> People will upgrade when >> the new features they want in the latest release outweigh the mythical pain >> of upgrading a JDK. > > Perhaps the technical pain of upgrade is largely mythical, but it's > real pain for real users who have no say over what version of Java > they can run (or at a minimum have to jump through a lot of hoops to > change the java version). Fully well aware of this, but trunk is not, by definition released, so there is nothing for them to upgrade to. > > There is no right answer... it's a judgement call where we should > weigh all the factors each time we require a new Java version. People > may weigh factors differently, but no factor should be dismissed out > of hand. Of course not, just saying I personally think trunk should move forward as fast as the regular contributors and committers want, which means, we decide/vote and then move on based on the outcome and that the branches (4x or 5x or whatever) should be slower to make any changes. People who take years to upgrade their JDK also likely take years to upgrade Lucene or Solr or whatever. I'm all for keeping and maintaining older branches for those who don't want to upgrade as long as the community is willing to support them. As for Doug's comments, I think they reflect a time when we only maintained one branch and it was more of a forced decision for users. It isn't as cut and dried anymore with multiple branches, services like Solr and ES, etc. I do agree, wholeheartedly however, that we should all be thoughtful and considerate of other's opinions in the process. -Grant - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
A little late to the game, but +1 on Java 8 on trunk. This bikeshed has gone on for countless years (go google moving to Java 5 like 8 years ago for Lucene) and you will never make everyone happy. People will upgrade when the new features they want in the latest release outweigh the mythical pain of upgrading a JDK. On Sep 15, 2014, at 12:44 AM, Shalin Shekhar Mangar wrote: > +1 > > If we asked our users we would still be using Java 5. Let's move trunk to > Java 8. We'd need to backport stuff to Java 7 based branches for a while > because users... but that's okay. > > On Fri, Sep 12, 2014 at 9:11 PM, Ryan Ernst wrote: > It has been 6 months since Java 8 was released. It has proven to be > both stable (no issues like with the initial release of java 7) and > faster. And there are a ton of features that would make our lives as > developers easier (and that can improve the quality of Lucene 5 when > it is eventually released). > > We should stay ahead of the curve, and move trunk to Java 8. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > -- > Regards, > Shalin Shekhar Mangar. Grant Ingersoll | @gsingers http://www.lucidworks.com
Re: [VOTE] Release 4.9.1 RC1
+1 On Sep 18, 2014, at 4:53 AM, Michael McCandless wrote: > Artifacts here: > http://people.apache.org/~mikemccand/staging_area/lucene-solr-4.9.1-RC1-rev1625909 > > Smoke tester: python3 -u dev-tools/scripts/smokeTestRelease.py > http://people.apache.org/~mikemccand/staging_area/lucene-solr-4.9.1-RC1-rev1625909 > 1625909 4.9.1 /tmp/smoke491 True > >> SUCCESS! [0:23:57.460556] > > Here's my +1 > > Mike McCandless > > http://blog.mikemccandless.com > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > Grant Ingersoll | @gsingers http://www.lucidworks.com
[jira] [Commented] (SOLR-6478) need docs / tests of the "rules" as far as collection names go
[ https://issues.apache.org/jira/browse/SOLR-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121305#comment-14121305 ] Grant Ingersoll commented on SOLR-6478: --- I suspect ome of the URLs, etc. get a little wonky when you allow things like spaces, etc. in the names. Not sure if we should allow them or not. > need docs / tests of the "rules" as far as collection names go > -- > > Key: SOLR-6478 > URL: https://issues.apache.org/jira/browse/SOLR-6478 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man > > historically, the rules for "core" names have been vague but implicitly > defined based on the rule that it had to be a valid directory path name - but > i don't know that we've ever documented anywhere what the rules are for a > "collection" name when dealing with the Collections API. > I haven't had a chance to try this, but i suspect that using the Collections > API you can create any collection name you want, and the zk/clusterstate.json > data will all be fine, and you'll then be able to request anything you want > from that collection as long as you properly URL escape it in your request > URLs ... but we should have a test that tries to do this, and document any > actual limitations that pop up and/or fix those limitations so we really can > have arbitrary collection names. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6478) need docs / tests of the "rules" as far as collection names go
[ https://issues.apache.org/jira/browse/SOLR-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121305#comment-14121305 ] Grant Ingersoll edited comment on SOLR-6478 at 9/4/14 12:44 PM: I suspect some of the URLs, etc. get a little wonky when you allow things like spaces, etc. in the names. Not sure if we should allow them or not. was (Author: gsingers): I suspect ome of the URLs, etc. get a little wonky when you allow things like spaces, etc. in the names. Not sure if we should allow them or not. > need docs / tests of the "rules" as far as collection names go > -- > > Key: SOLR-6478 > URL: https://issues.apache.org/jira/browse/SOLR-6478 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man > > historically, the rules for "core" names have been vague but implicitly > defined based on the rule that it had to be a valid directory path name - but > i don't know that we've ever documented anywhere what the rules are for a > "collection" name when dealing with the Collections API. > I haven't had a chance to try this, but i suspect that using the Collections > API you can create any collection name you want, and the zk/clusterstate.json > data will all be fine, and you'll then be able to request anything you want > from that collection as long as you properly URL escape it in your request > URLs ... but we should have a test that tries to do this, and document any > actual limitations that pop up and/or fix those limitations so we really can > have arbitrary collection names. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory
[ 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
[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory
[ https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14089943#comment-14089943 ] Grant Ingersoll commented on SOLR-3619: --- bq. Can we agree to start with 2 configsets (based on Hoss' plan above) and then work on converting the other examples iteratively I don't think getting started should require any knowledge of configsets, etc. You've already lost me as a new dev (I've seen this so many times in the past 2 years). Getting started is all about my data and my queries. I should only have to know enough to start indexing. Than, as I peel back the layer, I can dig in deeper. # bin/start # create new collection (Managed schema, field guessing) # Throw my JSON, CSV, PDFs, etc. at it and it does a reasonable first pass at it such that I can start iterating on how this all works. > 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
[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array
[ https://issues.apache.org/jira/browse/SOLR-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079792#comment-14079792 ] Grant Ingersoll commented on SOLR-6294: --- I really don't like having separate APIs for one doc vs. multiple docs. How about deprecating the existing approach in favor a new one that properly captures commands, single docs, and multiple docs and is clean for users? The whole point of stuff like this is to make it easier for people first coming to Solr to not have to think about all the gotchas and just get their data in. Ease of use has to be all about the user's data and their questions for it, not about idiosyncrasies in API design to workaround previous approaches. > The JsonLoader should accept a single doc without wrapping in an array > -- > > Key: SOLR-6294 > URL: https://issues.apache.org/jira/browse/SOLR-6294 > Project: Solr > Issue Type: Bug > Components: update >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > > This is the multi document input command > {noformat} > curl http://localhost:8983/solr/update/json -H > 'Content-type:application/json' -d ' > [ > {"id" : "TestDoc1", "title" : "test1"}, > ]' > {noformat} > The following also should be a valid update command for a single doc > {noformat} > curl http://localhost:8983/solr/update/json -H > 'Content-type:application/json' -d ' > {"id" : "TestDoc1", "title" : "test1"}, > ' > {noformat} -- 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
[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array
[ https://issues.apache.org/jira/browse/SOLR-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078154#comment-14078154 ] Grant Ingersoll commented on SOLR-6294: --- bq. Is that really easier than putting the doc in an array? If you're data already is written out in JSON and you just want to get started by throwing it into Solr in your first few minutes of trying it out, it could be. Just one more thing to have to deal with, I guess, but obviously not a show stopper by any stretch. > The JsonLoader should accept a single doc without wrapping in an array > -- > > Key: SOLR-6294 > URL: https://issues.apache.org/jira/browse/SOLR-6294 > Project: Solr > Issue Type: Bug > Components: update >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > > This is the multi document input command > {noformat} > curl http://localhost:8983/solr/update/json -H > 'Content-type:application/json' -d ' > [ > {"id" : "TestDoc1", "title" : "test1"}, > ]' > {noformat} > The following also should be a valid update command for a single doc > {noformat} > curl http://localhost:8983/solr/update/json -H > 'Content-type:application/json' -d ' > {"id" : "TestDoc1", "title" : "test1"}, > ' > {noformat} -- 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
[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory
[ https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14068403#comment-14068403 ] Grant Ingersoll commented on SOLR-3619: --- bq. Yeah, it feels like one should still be able to start the server and then index a document (as they can do now) without any other mandatory steps. +1 Agree, single core dies, collection1 dies. Everything should just work out of the box! The first 5 minute experience should be all about the user and their data and very little to do about solr configs, schemas, etc. Same for pretty much the whole first day. By the end of the first week, a new user should have a thorough understanding of what they need to do to get to production. "Easy to start, easy to finish". > 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 > Fix For: 4.9, 5.0 > > Attachments: SOLR-3619.patch, server-name-layout.png > > -- 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
[jira] [Commented] (LUCENE-5688) NumericDocValues fields with sparse data can be compressed better
[ https://issues.apache.org/jira/browse/LUCENE-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003231#comment-14003231 ] Grant Ingersoll commented on LUCENE-5688: - bq. Varun, i dont think we should make a long[] of size maxDoc in ram here just to save some space on disk. In a large index, this can be quite significant, FWIW. Agreed on the long[] in RAM, but would be good to have a better way of controlling the on-disk behavior. > NumericDocValues fields with sparse data can be compressed better > -- > > Key: LUCENE-5688 > URL: https://issues.apache.org/jira/browse/LUCENE-5688 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Varun Thacker >Priority: Minor > Attachments: LUCENE-5688.patch > > > I ran into this problem where I had a dynamic field in Solr and indexed data > into lots of fields. For each field only a few documents had actual values > and the remaining documents the default value ( 0 ) got indexed. Now when I > merge segments, the index size jumps up. > For example I have 10 segments - Each with 1 DV field. When I merge segments > into 1 that segment will contain all 10 DV fields with lots if 0s. > This was the motivation behind trying to come up with a compression for a use > case like this. -- 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
[jira] [Created] (SOLR-6078) Create First Day Documentation
Grant Ingersoll created SOLR-6078: - Summary: Create First Day Documentation Key: SOLR-6078 URL: https://issues.apache.org/jira/browse/SOLR-6078 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll As one progresses from getting started with Solr, it is important to show how their work will develop from simple acts with basic data sets, to more complex. This tutorial should highlight what a user is likely to need to know in their first day with Solr. -- 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
[jira] [Created] (SOLR-6077) Create 5 minute tutorial
Grant Ingersoll created SOLR-6077: - Summary: Create 5 minute tutorial Key: SOLR-6077 URL: https://issues.apache.org/jira/browse/SOLR-6077 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Per the new site design for Solr, we'd like to have a 5 minutes to Solr tutorial that covers users getting their data in and querying it. -- 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
[jira] [Created] (SOLR-6080) Getting Finished Docs
Grant Ingersoll created SOLR-6080: - Summary: Getting Finished Docs Key: SOLR-6080 URL: https://issues.apache.org/jira/browse/SOLR-6080 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll It's one thing to be easy to start, it's a whole other level to "get finished", and getting to production and being stable is one of Solr's strongest suits, thanks to it's maturity and testing. This section of the website should highlight what user's need to know about getting to production and maintaining a happy cluster. This can dovetail with the Ref Guide's "Well configured Solr section" -- 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
[jira] [Created] (SOLR-6079) First week Docs
Grant Ingersoll created SOLR-6079: - Summary: First week Docs Key: SOLR-6079 URL: https://issues.apache.org/jira/browse/SOLR-6079 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Over the course of the week, we want to highlight the things users need to think about as the go from novice to production. The goal here is to provide just enough info along the way about the underpinnings of Solr while staying focused on the user's data and queries. -- 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
[jira] [Created] (SOLR-6081) Hook in Videos, Books, Reference work
Grant Ingersoll created SOLR-6081: - Summary: Hook in Videos, Books, Reference work Key: SOLR-6081 URL: https://issues.apache.org/jira/browse/SOLR-6081 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll There is a ton of great content available on Solr in the interwebs, let's make it easy to highlight this content so users know their is a large community ready to assist. -- 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
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998709#comment-13998709 ] Grant Ingersoll commented on SOLR-6058: --- [~L_Nino] Thanks for uploading. Next step would be to generate a patch for the current site using the instructions here: http://lucene.apache.org/site-instructions.html Let me know if you need help. I'm going to spin out some sub tasks that will handle overhauling the content. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- 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
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997995#comment-13997995 ] Grant Ingersoll commented on SOLR-6058: --- bq. Also the Lucene website? Sure thing. Would love your help on the content side of it. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > Attachments: HTML.rar > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- 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
[jira] [Created] (SOLR-6058) Solr needs a new website
Grant Ingersoll created SOLR-6058: - Summary: Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- 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
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994503#comment-13994503 ] Grant Ingersoll commented on SOLR-6058: --- LucidWorks has hired a designer to overhaul the Solr website. He will be uploading a draft soon for people to start previewing after which we can convert it to the CMS format. From there, we will need people to help on the content side of things. > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task > Reporter: Grant Ingersoll > Assignee: Grant Ingersoll > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- 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
Re: VOTE: RC1 Release apache-solr-ref-guide-4.8.pdf
+1 On Apr 25, 2014, at 5:38 PM, Chris Hostetter wrote: > > (Note: cross posted to general, please confine replies to dev@lucene) > > Please VOTE to release the following RC1 as apache-solr-ref-guide-4.8.pdf ... > > https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.8-RC1 > > > The notes I previously mentioned regarding RC0 apply to this RC as well... > > 1) Due to a known bug in confluence, the PDFs it generates are much bigger > then they should be. This bug has been fixed in the latest version of > confluence, but cwiki.apache.rog has not yet been updated. For that reason, > I have manually run a small tool against the PDF to "fix" the size (see > SOLR-5819). The first time i tried this approach, it inadvertantly removed > the "Index" (aka: Table of Contents, or Bookmarks depending on what PDF > reader client you use). I've already fixed this, but if you notice anything > else unusual about this PDF compared to previous versions please speak up so > we can see if it's a result of this post-processing and try to fix it. > > 2) This is the first ref guide release where we've started using a special > confluence macro for any lucene/solr javadoc links. The up side is that all > javadoc links in this 4.8 ref guide will now correctly point to the 4.8 > javadocs on lucene.apache.org -- the down side is that this means none of > those links currently work, since the 4.8 code release is still ongoing and > the website has not yet been updated. > > Because of #2, I intend to leave this ref guide vote open until the 4.8 code > release is final - that way we won't officially be releasing this doc until > the 4.8 javadocs are uploaded and all the links work properly. > > > > -Hoss > http://www.lucidworks.com/ Grant Ingersoll | @gsingers http://www.lucidworks.com