[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799205#comment-13799205 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533517 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533517 ] LUCENE-4956: Make parser more strict, remove bullshit from data files > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799214#comment-13799214 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533521 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533521 ] LUCENE-4956: Unify Exceptions > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5353) Enhance CoreAdmin api to split a route key's documents from an index
[ https://issues.apache.org/jira/browse/SOLR-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799234#comment-13799234 ] ASF subversion and git services commented on SOLR-5353: --- Commit 1533528 from sha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1533528 ] SOLR-5353: Allow CoreAdmin split to accept a single range only > Enhance CoreAdmin api to split a route key's documents from an index > > > Key: SOLR-5353 > URL: https://issues.apache.org/jira/browse/SOLR-5353 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5353-allow-single-range.patch, SOLR-5353.patch > > > Allow a split key to be passed in to CoreAdmin SPLIT action so that we can > split only a particular route key's documents out of the index. > e.g. consider an index containing documents belonging to two route keys with > hash ranges A!=[12,15] and B!=[13,17]. We want to split all documents having > route key 'A!' while leaving behind any documents having route key 'B!' even > though some documents with 'B!' fall into the hash range of 'A!' > This is different from what was achieved in SOLR-5338 because that issue > splits all documents belonging to the hash range of a given route key. Since > multiple keys can have overlapping hash range and we were splitting into the > same collection, we had no choice but to move all documents belonging to the > hash range into the new shard. > In this particular issue, we are trying to migrate documents to a different > collection and therefore we can leave documents having other route keys > behind. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799276#comment-13799276 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533550 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533550 ] LUCENE-4956: Tagger is completely dead code! Why did I put work into it? > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799274#comment-13799274 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533549 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533549 ] LUCENE-4956: add TestCoverageHack > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799290#comment-13799290 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533557 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533557 ] LUCENE-4956: remove empty dir > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799314#comment-13799314 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533562 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533562 ] LUCENE-4956: remove some dead code > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5216) Document updates to SolrCloud can cause a distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799577#comment-13799577 ] ASF subversion and git services commented on SOLR-5216: --- Commit 1533649 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533649 ] SOLR-5216: Document updates to SolrCloud can cause a distributed deadlock. SOLR-5232: SolrCloud should distribute updates via streaming rather than buffering. > Document updates to SolrCloud can cause a distributed deadlock. > --- > > Key: SOLR-5216 > URL: https://issues.apache.org/jira/browse/SOLR-5216 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: 4.6, 5.0 > > Attachments: SOLR-5216.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5232) SolrCloud should distribute updates via streaming rather than buffering.
[ https://issues.apache.org/jira/browse/SOLR-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799578#comment-13799578 ] ASF subversion and git services commented on SOLR-5232: --- Commit 1533649 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533649 ] SOLR-5216: Document updates to SolrCloud can cause a distributed deadlock. SOLR-5232: SolrCloud should distribute updates via streaming rather than buffering. > SolrCloud should distribute updates via streaming rather than buffering. > > > Key: SOLR-5232 > URL: https://issues.apache.org/jira/browse/SOLR-5232 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: 4.6, 5.0 > > Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch, > SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch > > > The current approach was never the best for SolrCloud - it was designed for a > pre SolrCloud Solr - it also uses too many connections and threads - nailing > that down is likely wasted effort when we should really move away from > explicitly buffering docs and sending small batches per thread as we have > been doing. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5216) Document updates to SolrCloud can cause a distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799585#comment-13799585 ] ASF subversion and git services commented on SOLR-5216: --- Commit 1533652 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533652 ] SOLR-5216: Document updates to SolrCloud can cause a distributed deadlock. SOLR-5232: SolrCloud should distribute updates via streaming rather than buffering. > Document updates to SolrCloud can cause a distributed deadlock. > --- > > Key: SOLR-5216 > URL: https://issues.apache.org/jira/browse/SOLR-5216 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: 4.6, 5.0 > > Attachments: SOLR-5216.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5232) SolrCloud should distribute updates via streaming rather than buffering.
[ https://issues.apache.org/jira/browse/SOLR-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799586#comment-13799586 ] ASF subversion and git services commented on SOLR-5232: --- Commit 1533652 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533652 ] SOLR-5216: Document updates to SolrCloud can cause a distributed deadlock. SOLR-5232: SolrCloud should distribute updates via streaming rather than buffering. > SolrCloud should distribute updates via streaming rather than buffering. > > > Key: SOLR-5232 > URL: https://issues.apache.org/jira/browse/SOLR-5232 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: 4.6, 5.0 > > Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch, > SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch > > > The current approach was never the best for SolrCloud - it was designed for a > pre SolrCloud Solr - it also uses too many connections and threads - nailing > that down is likely wasted effort when we should really move away from > explicitly buffering docs and sending small batches per thread as we have > been doing. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5367) Unmarsheling delete by Id with JavaBin can lead to class cast exception.
[ https://issues.apache.org/jira/browse/SOLR-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799748#comment-13799748 ] ASF subversion and git services commented on SOLR-5367: --- Commit 1533683 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533683 ] SOLR-5367: Unmarshalling delete by id commands with JavaBin can lead to class cast exception. > Unmarsheling delete by Id with JavaBin can lead to class cast exception. > > > Key: SOLR-5367 > URL: https://issues.apache.org/jira/browse/SOLR-5367 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5, 4.5.1 >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > This is exposed by tests with the changes in SOLR-5223 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5223) SolrCloud should use JavaBin communication by default.
[ https://issues.apache.org/jira/browse/SOLR-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799749#comment-13799749 ] ASF subversion and git services commented on SOLR-5223: --- Commit 1533684 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533684 ] SOLR-5223: SolrCloud should use the JavaBin binary format for communication by default. > SolrCloud should use JavaBin communication by default. > -- > > Key: SOLR-5223 > URL: https://issues.apache.org/jira/browse/SOLR-5223 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5223.patch, SOLR-5223.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5367) Unmarsheling delete by Id with JavaBin can lead to class cast exception.
[ https://issues.apache.org/jira/browse/SOLR-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799750#comment-13799750 ] ASF subversion and git services commented on SOLR-5367: --- Commit 1533685 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533685 ] SOLR-5367: Unmarshalling delete by id commands with JavaBin can lead to class cast exception. > Unmarsheling delete by Id with JavaBin can lead to class cast exception. > > > Key: SOLR-5367 > URL: https://issues.apache.org/jira/browse/SOLR-5367 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5, 4.5.1 >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > This is exposed by tests with the changes in SOLR-5223 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5223) SolrCloud should use JavaBin communication by default.
[ https://issues.apache.org/jira/browse/SOLR-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799755#comment-13799755 ] ASF subversion and git services commented on SOLR-5223: --- Commit 1533686 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533686 ] SOLR-5223: SolrCloud should use the JavaBin binary format for communication by default. > SolrCloud should use JavaBin communication by default. > -- > > Key: SOLR-5223 > URL: https://issues.apache.org/jira/browse/SOLR-5223 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5223.patch, SOLR-5223.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799794#comment-13799794 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533695 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533695 ] LUCENE-4956: move data to src/data and setup regeneration (for now simple copy) > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799835#comment-13799835 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533709 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533709 ] LUCENE-4956: Remove unused file constants > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799937#comment-13799937 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533781 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533781 ] LUCENE-4956: allow use of these with datainput > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4965) Add dynamic numeric range faceting
[ https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799938#comment-13799938 ] ASF subversion and git services commented on LUCENE-4965: - Commit 1533782 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533782 ] LUCENE-4965: don't expose this as a large hashmap with thousands of arrays > Add dynamic numeric range faceting > -- > > Key: LUCENE-4965 > URL: https://issues.apache.org/jira/browse/LUCENE-4965 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.4, 5.0 > > Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, > LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, > LUCENE-4965.patch > > > The facet module today requires the app to compute the hierarchy > at index time, eg a timestamp field might use a year/month/day > hierarchy. > While this gives great performance, since it minimizes the search-time > computation, sometimes it's unfortunately useful/necessary to do things > entirely at > search time, like Solr does. > E.g. I'm playing with a prototype Lucene search for Jira issues > and I'd like to add a drill down+sideways for "Updated in past day, > 2 days, week, month" etc. But because time is constantly advancing, > doing this at index time is a not easy ... -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5359) CloudSolrServer tries to connect to zookeeper forever when ensemble is unavailable
[ https://issues.apache.org/jira/browse/SOLR-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799946#comment-13799946 ] ASF subversion and git services commented on SOLR-5359: --- Commit 1533786 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533786 ] SOLR-5359: ZooKeeper client is not closed when it fails to connect to an ensemble. > CloudSolrServer tries to connect to zookeeper forever when ensemble is > unavailable > -- > > Key: SOLR-5359 > URL: https://issues.apache.org/jira/browse/SOLR-5359 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.5 >Reporter: Klaus Herrmann >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > Attachments: SOLR-5359.patch > > > When opening a new CloudSolrServer against an unavailable zookeeper ensemble, > the following exception messages are logged: > INFO [hybrisHTTP28-SendThread(localhost:2181)] [ClientCnxn] Opening socket > connection to server localhost/127.0.0.1:2181. Will not attempt to > authenticate using SASL (unknown error) > WARN [hybrisHTTP28-SendThread(localhost:2181)] [ClientCnxn] Session 0x0 for > server null, unexpected error, closing socket connection and attempting > reconnect > java.net.ConnectException: Connection refused > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:692) > at > org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1068) > INFO [hybrisHTTP28-SendThread(localhost:2181)] [ClientCnxn] Opening socket > connection to server localhost/127.0.0.1:2181. Will not attempt to > authenticate using SASL (unknown error) > WARN [hybrisHTTP28-SendThread(localhost:2181)] [ClientCnxn] Session 0x0 for > server null, unexpected error, closing socket connection and attempting > reconnect > java.net.ConnectException: Connection refused > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:692) > at > org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1068) > This is consistent with the behaviour of zkCli.sh - however, it does never > timeout. zkCli.sh stops connecting after 30 seconds, but the zookeeper > connection attempts by CloudSolrServer show the above messages forever, > regardless of ZkClientTimeout and ZkConnectTimeout. > Calls to e.g. isAlive() do indeed time out, but that does not stop the > underlying CloudSolrServer instance from connecting. > It does not seem to be possible to set a different zkHost for an existing > CloudSolrServer instance either, so once an instance is created with a > bad/wrong zkHost string it seems impossible to destroy. > Even if the zkHost were correct and just the ensemble down one has to keep > around the CloudSolrService and not dismiss it after a failed connection > attempt - otherwise each try will generate a new ZkClient that then attempts > to conncet forever, leading to more and more client attempts, as the clients > never stop and are never garbage collected. > I believe the CloudSolrService/ZkClient should stop trying to connect > altogether after a timeout and be garbage collected. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5359) CloudSolrServer tries to connect to zookeeper forever when ensemble is unavailable
[ https://issues.apache.org/jira/browse/SOLR-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799947#comment-13799947 ] ASF subversion and git services commented on SOLR-5359: --- Commit 1533788 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533788 ] SOLR-5359: ZooKeeper client is not closed when it fails to connect to an ensemble. > CloudSolrServer tries to connect to zookeeper forever when ensemble is > unavailable > -- > > Key: SOLR-5359 > URL: https://issues.apache.org/jira/browse/SOLR-5359 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.5 >Reporter: Klaus Herrmann >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > Attachments: SOLR-5359.patch > > > When opening a new CloudSolrServer against an unavailable zookeeper ensemble, > the following exception messages are logged: > INFO [hybrisHTTP28-SendThread(localhost:2181)] [ClientCnxn] Opening socket > connection to server localhost/127.0.0.1:2181. Will not attempt to > authenticate using SASL (unknown error) > WARN [hybrisHTTP28-SendThread(localhost:2181)] [ClientCnxn] Session 0x0 for > server null, unexpected error, closing socket connection and attempting > reconnect > java.net.ConnectException: Connection refused > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:692) > at > org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1068) > INFO [hybrisHTTP28-SendThread(localhost:2181)] [ClientCnxn] Opening socket > connection to server localhost/127.0.0.1:2181. Will not attempt to > authenticate using SASL (unknown error) > WARN [hybrisHTTP28-SendThread(localhost:2181)] [ClientCnxn] Session 0x0 for > server null, unexpected error, closing socket connection and attempting > reconnect > java.net.ConnectException: Connection refused > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:692) > at > org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1068) > This is consistent with the behaviour of zkCli.sh - however, it does never > timeout. zkCli.sh stops connecting after 30 seconds, but the zookeeper > connection attempts by CloudSolrServer show the above messages forever, > regardless of ZkClientTimeout and ZkConnectTimeout. > Calls to e.g. isAlive() do indeed time out, but that does not stop the > underlying CloudSolrServer instance from connecting. > It does not seem to be possible to set a different zkHost for an existing > CloudSolrServer instance either, so once an instance is created with a > bad/wrong zkHost string it seems impossible to destroy. > Even if the zkHost were correct and just the ensemble down one has to keep > around the CloudSolrService and not dismiss it after a failed connection > attempt - otherwise each try will generate a new ZkClient that then attempts > to conncet forever, leading to more and more client attempts, as the clients > never stop and are never garbage collected. > I believe the CloudSolrService/ZkClient should stop trying to connect > altogether after a timeout and be garbage collected. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5357) Schemaless example does not contain a solr.xml
[
https://issues.apache.org/jira/browse/SOLR-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799949#comment-13799949
]
ASF subversion and git services commented on SOLR-5357:
---
Commit 1533789 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1533789 ]
SOLR-5357: add solr.xml to schemaless solrhome
> Schemaless example does not contain a solr.xml
> --
>
> Key: SOLR-5357
> URL: https://issues.apache.org/jira/browse/SOLR-5357
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0
>Reporter: Varun Thacker
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.6, 5.0
>
>
> The example-schemaless example does not contain solr.xml
> So when you run the example using {code} java
> -Dsolr.solr.home=example-schemaless/solr -jar start.jar {code} Solr fails to
> start and an exception is thrown.
> {code}
> Caused by: org.apache.solr.common.SolrException: solr.xml does not exist in
> /Users/varun/search-work/lucene-trunk/solr/example/example-schemaless/solr/solr.xml
> cannot start Solr
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5295) Allow the license checker to optionally avoid check sum comparisons.
[ https://issues.apache.org/jira/browse/LUCENE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799952#comment-13799952 ] ASF subversion and git services commented on LUCENE-5295: - Commit 1533792 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533792 ] LUCENE-5295: Allow the license checker to optionally avoid check sum comparisons. > Allow the license checker to optionally avoid check sum comparisons. > > > Key: LUCENE-5295 > URL: https://issues.apache.org/jira/browse/LUCENE-5295 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5295.patch, LUCENE-5295.patch > > > Similar motivation as LUCENE-5209 and same implementation. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5295) Allow the license checker to optionally avoid check sum comparisons.
[ https://issues.apache.org/jira/browse/LUCENE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799950#comment-13799950 ] ASF subversion and git services commented on LUCENE-5295: - Commit 1533791 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533791 ] LUCENE-5295: Allow the license checker to optionally avoid check sum comparisons. > Allow the license checker to optionally avoid check sum comparisons. > > > Key: LUCENE-5295 > URL: https://issues.apache.org/jira/browse/LUCENE-5295 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5295.patch, LUCENE-5295.patch > > > Similar motivation as LUCENE-5209 and same implementation. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5361) Hit Schemaless example with some tests.
[ https://issues.apache.org/jira/browse/SOLR-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799959#comment-13799959 ] ASF subversion and git services commented on SOLR-5361: --- Commit 1533801 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533801 ] SOLR-5361: Hit Schemaless example with some tests. > Hit Schemaless example with some tests. > --- > > Key: SOLR-5361 > URL: https://issues.apache.org/jira/browse/SOLR-5361 > Project: Solr > Issue Type: Test >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: 4.6, 5.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5361) Hit Schemaless example with some tests.
[ https://issues.apache.org/jira/browse/SOLR-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799960#comment-13799960 ] ASF subversion and git services commented on SOLR-5361: --- Commit 1533802 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533802 ] SOLR-5361: Hit Schemaless example with some tests. > Hit Schemaless example with some tests. > --- > > Key: SOLR-5361 > URL: https://issues.apache.org/jira/browse/SOLR-5361 > Project: Solr > Issue Type: Test >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: 4.6, 5.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5328) Errant numShards in test solr.xml
[ https://issues.apache.org/jira/browse/SOLR-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799974#comment-13799974 ] ASF subversion and git services commented on SOLR-5328: --- Commit 1533806 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533806 ] SOLR-5328: Errant numShards in test solr.xml > Errant numShards in test solr.xml > - > > Key: SOLR-5328 > URL: https://issues.apache.org/jira/browse/SOLR-5328 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Trivial > Fix For: 4.6, 5.0 > > Attachments: SOLR-5328.patch > > > Another bug introduced by the recent re factoring in this area. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5328) Errant numShards in test solr.xml
[ https://issues.apache.org/jira/browse/SOLR-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799975#comment-13799975 ] ASF subversion and git services commented on SOLR-5328: --- Commit 1533807 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533807 ] SOLR-5328: Errant numShards in test solr.xml > Errant numShards in test solr.xml > - > > Key: SOLR-5328 > URL: https://issues.apache.org/jira/browse/SOLR-5328 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Trivial > Fix For: 4.6, 5.0 > > Attachments: SOLR-5328.patch > > > Another bug introduced by the recent re factoring in this area. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4998) be more precise about IOContext for reads
[
https://issues.apache.org/jira/browse/LUCENE-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799980#comment-13799980
]
ASF subversion and git services commented on LUCENE-4998:
-
Commit 1533808 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1533808 ]
LUCENE-4998: add DocumentExpressionDictionary, to compute each suggestion's
weight using a javascript expression
> be more precise about IOContext for reads
> -
>
> Key: LUCENE-4998
> URL: https://issues.apache.org/jira/browse/LUCENE-4998
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Shikhar Bhushan
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 4.5.1, 4.6, 5.0
>
> Attachments: LUCENE-4998.patch
>
>
> Set the context as {{IOContext.READ}} / {{IOContext.READONCE}} where
> applicable
>
> Motivation:
> Custom {{PostingsFormat}} may want to check the context on
> {{SegmentReadState}} and branch differently, but for this to work properly
> the context has to be specified correctly up the stack.
> For example, {{DirectPostingsFormat}} only loads postings into memory if the
> {{context != MERGE}}. However a better condition would be {{context ==
> Context.READ && !context.readOnce}}.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4998) be more precise about IOContext for reads
[
https://issues.apache.org/jira/browse/LUCENE-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799981#comment-13799981
]
ASF subversion and git services commented on LUCENE-4998:
-
Commit 1533809 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1533809 ]
LUCENE-4998: add DocumentExpressionDictionary, to compute each suggestion's
weight using a javascript expression
> be more precise about IOContext for reads
> -
>
> Key: LUCENE-4998
> URL: https://issues.apache.org/jira/browse/LUCENE-4998
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Shikhar Bhushan
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 4.5.1, 4.6, 5.0
>
> Attachments: LUCENE-4998.patch
>
>
> Set the context as {{IOContext.READ}} / {{IOContext.READONCE}} where
> applicable
>
> Motivation:
> Custom {{PostingsFormat}} may want to check the context on
> {{SegmentReadState}} and branch differently, but for this to work properly
> the context has to be specified correctly up the stack.
> For example, {{DirectPostingsFormat}} only loads postings into memory if the
> {{context != MERGE}}. However a better condition would be {{context ==
> Context.READ && !context.readOnce}}.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799989#comment-13799989 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533813 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533813 ] LUCENE-4956: refactor syllable handling to not be a list of thousands of arrays > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1371#comment-1371 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533815 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533815 ] LUCENE-4956: Fix error handling in HanjaUtil to prevent NPE on broken classpath > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1372#comment-1372 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533817 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533817 ] LUCENE-4956: Fix error handling in HanjaUtil to prevent NPE on broken classpath > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5294) Suggester Dictionary implementation that takes expressions as term weights
[ https://issues.apache.org/jira/browse/LUCENE-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1374#comment-1374 ] ASF subversion and git services commented on LUCENE-5294: - Commit 1533820 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1533820 ] LUCENE-5294: try to fix maven build > Suggester Dictionary implementation that takes expressions as term weights > -- > > Key: LUCENE-5294 > URL: https://issues.apache.org/jira/browse/LUCENE-5294 > Project: Lucene - Core > Issue Type: New Feature > Components: core/search >Reporter: Areek Zillur > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5294.patch > > > It would be nice to have a Suggester Dictionary implementation that could > compute the weights of the terms consumed by the suggester based on an > user-defined expression (using lucene's expression module). > It could be an extension of the existing DocumentDictionary (which takes > terms, weights and (optionally) payloads from the stored documents in the > index). The only exception being that instead of taking the weights for the > terms from the specified weight fields, it could compute the weights using an > user-defn expression, that uses one or more NumicDocValuesField from the > document. > Example: > let the document have > - product_id > - product_name > - product_popularity > - product_profit > Then this implementation could be used with an expression of > "0.2*product_popularity + 0.8*product_profit" to determine the weights of the > terms for the corresponding documents (optionally along with a payload > (product_id)) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1375#comment-1375 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533821 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533821 ] LUCENE-4956: Use IOUtils.decodingReader to load data files > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5294) Suggester Dictionary implementation that takes expressions as term weights
[ https://issues.apache.org/jira/browse/LUCENE-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1376#comment-1376 ] ASF subversion and git services commented on LUCENE-5294: - Commit 1533822 from [~mikemccand] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533822 ] LUCENE-5294: try to fix maven build > Suggester Dictionary implementation that takes expressions as term weights > -- > > Key: LUCENE-5294 > URL: https://issues.apache.org/jira/browse/LUCENE-5294 > Project: Lucene - Core > Issue Type: New Feature > Components: core/search >Reporter: Areek Zillur > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5294.patch > > > It would be nice to have a Suggester Dictionary implementation that could > compute the weights of the terms consumed by the suggester based on an > user-defined expression (using lucene's expression module). > It could be an extension of the existing DocumentDictionary (which takes > terms, weights and (optionally) payloads from the stored documents in the > index). The only exception being that instead of taking the weights for the > terms from the specified weight fields, it could compute the weights using an > user-defn expression, that uses one or more NumicDocValuesField from the > document. > Example: > let the document have > - product_id > - product_name > - product_popularity > - product_profit > Then this implementation could be used with an expression of > "0.2*product_popularity + 0.8*product_profit" to determine the weights of the > terms for the corresponding documents (optionally along with a payload > (product_id)) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1381#comment-1381 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533835 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533835 ] LUCENE-4956: more cleanups and visibility fixes > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800011#comment-13800011 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533838 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533838 ] LUCENE-4956: Move/Rename some files and make pkg-private > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800034#comment-13800034 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533842 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533842 ] LUCENE-4956: Fix stopwords file, Cleanup analyzer (load stopwords file, no hardcoded stops), and filter (fix broken incrementToken, implement reset), remove unused varaibles in CompoundNounAnalyzer > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800035#comment-13800035 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533843 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533843 ] LUCENE-4956: Make filter final, add one more nocommit > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800049#comment-13800049 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533846 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533846 ] LUCENE-4956: Fix factory to check for incorrect parameter keys, remove bogus parameters, remove bogus matchVersion on KoreanTokenizer > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800098#comment-13800098 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533857 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533857 ] LUCENE-4956: Partially fix posIncrAtt to preserve increment of first token. The morphQueue still has a bug, added nocommit! > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800099#comment-13800099 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533858 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533858 ] LUCENE-4956: Rename IndexWord to Token like in Kuromoji! > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800108#comment-13800108 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533862 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533862 ] LUCENE-4956: Simplier fix for the broken posIncr. I also cleaned up the Token class and made private to the Filter > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800110#comment-13800110 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533863 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533863 ] LUCENE-4956: Remove useless getters in private class > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800113#comment-13800113 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533865 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533865 ] LUCENE-4956: fix malformed entries > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4998) be more precise about IOContext for reads
[
https://issues.apache.org/jira/browse/LUCENE-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800116#comment-13800116
]
ASF subversion and git services commented on LUCENE-4998:
-
Commit 1533870 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1533870 ]
LUCENE-4998: can't use Lucene3x (test requires doc values)
> be more precise about IOContext for reads
> -
>
> Key: LUCENE-4998
> URL: https://issues.apache.org/jira/browse/LUCENE-4998
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Shikhar Bhushan
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 4.5.1, 4.6, 5.0
>
> Attachments: LUCENE-4998.patch
>
>
> Set the context as {{IOContext.READ}} / {{IOContext.READONCE}} where
> applicable
>
> Motivation:
> Custom {{PostingsFormat}} may want to check the context on
> {{SegmentReadState}} and branch differently, but for this to work properly
> the context has to be specified correctly up the stack.
> For example, {{DirectPostingsFormat}} only loads postings into memory if the
> {{context != MERGE}}. However a better condition would be {{context ==
> Context.READ && !context.readOnce}}.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800117#comment-13800117 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533872 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533872 ] LUCENE-4956: remove slow caseless match in trie, don't read headers as actual entries > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800123#comment-13800123 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533877 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533877 ] LUCENE-4956: ban dictionary corrumption > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800156#comment-13800156 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1533923 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1533923 ] LUCENE-4956: Rewrite iterator-consumer; make "stupid" Exception more selective. I have no idea how to fix! > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5369) org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate fails.
[
https://issues.apache.org/jira/browse/SOLR-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800165#comment-13800165
]
ASF subversion and git services commented on SOLR-5369:
---
Commit 1533929 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1533929 ]
SOLR-5369: first try - wait a little longer
> org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate fails.
> --
>
> Key: SOLR-5369
> URL: https://issues.apache.org/jira/browse/SOLR-5369
> Project: Solr
> Issue Type: Test
>Reporter: Mark Miller
>Priority: Minor
>
> {code}
> org.junit.ComparisonFailure: expected:<[in]active> but was:<[]active>
> at
> __randomizedtesting.SeedInfo.seed([C27BE35BC5D6502D:12196E179B038AA9]:0)
> at org.junit.Assert.assertEquals(Assert.java:125)
> at org.junit.Assert.assertEquals(Assert.java:147)
> at
> org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:183)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5369) org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate fails.
[
https://issues.apache.org/jira/browse/SOLR-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800167#comment-13800167
]
ASF subversion and git services commented on SOLR-5369:
---
Commit 1533930 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1533930 ]
SOLR-5369: first try - wait a little longer
> org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate fails.
> --
>
> Key: SOLR-5369
> URL: https://issues.apache.org/jira/browse/SOLR-5369
> Project: Solr
> Issue Type: Test
>Reporter: Mark Miller
>Priority: Minor
>
> {code}
> org.junit.ComparisonFailure: expected:<[in]active> but was:<[]active>
> at
> __randomizedtesting.SeedInfo.seed([C27BE35BC5D6502D:12196E179B038AA9]:0)
> at org.junit.Assert.assertEquals(Assert.java:125)
> at org.junit.Assert.assertEquals(Assert.java:147)
> at
> org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:183)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5042) MoreLikeThis doesn't return a score when mlt.count is set to 10
[ https://issues.apache.org/jira/browse/SOLR-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800249#comment-13800249 ] ASF subversion and git services commented on SOLR-5042: --- Commit 1533995 from [~elyograg] in branch 'dev/trunk' [ https://svn.apache.org/r1533995 ] SOLR-5042 SOLR-5125 SOLR-5368: mlt.count used incorrectly in MoreLikeThisComponent. > MoreLikeThis doesn't return a score when mlt.count is set to 10 > --- > > Key: SOLR-5042 > URL: https://issues.apache.org/jira/browse/SOLR-5042 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.3 >Reporter: Josh Curran >Priority: Minor > Attachments: SOLR-5042.patch > > > The problem appears to be around the mlt.count with in the solrconfig.xml. > When this value is set to 10, the 10 values that have been identified as > 'most like this' are returned with the original query, however the 'score' > field is missing. > Changing the mlt.count to say 11 and issuing the same query then the 'score' > field is returned with the same query. This appears to be the workaround. 11 > was just an arbitrary value, 12 or 15 also work > The same problem was raised on stackoverflow > http://stackoverflow.com/questions/16513719/solr-more-like-this-dont-return-score-while-specify-mlt-count -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5368) Morelikethis throw EarlyTerminatingCollectorException,when the document is greater than 5
[ https://issues.apache.org/jira/browse/SOLR-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800251#comment-13800251 ] ASF subversion and git services commented on SOLR-5368: --- Commit 1533995 from [~elyograg] in branch 'dev/trunk' [ https://svn.apache.org/r1533995 ] SOLR-5042 SOLR-5125 SOLR-5368: mlt.count used incorrectly in MoreLikeThisComponent. > Morelikethis throw EarlyTerminatingCollectorException,when the document is > greater than 5 > - > > Key: SOLR-5368 > URL: https://issues.apache.org/jira/browse/SOLR-5368 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.4 >Reporter: dejie Chang >Priority: Critical > > when i use MoreLikeThisHandler，it throws a EarlyTerminatingCollectorException > when the document is greater than 5. > and I think it is because the fllowing reason in MoreLikeThisComponent.java > NamedList sim = getMoreLikeThese(rb, rb.req.getSearcher(), > rb.getResults().docList, mltcount); > But the actual getMoreLikeThese's The method signature is > NamedList getMoreLikeThese(ResponseBuilder rb, > SolrIndexSearcher searcher, DocList docs, int flags) > so i think the mltcount shoud be flags。 > and also on line 113 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5125) Distributed MoreLikeThis fails with NullPointerException, shard query gives EarlyTerminatingCollectorException
[ https://issues.apache.org/jira/browse/SOLR-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800250#comment-13800250 ] ASF subversion and git services commented on SOLR-5125: --- Commit 1533995 from [~elyograg] in branch 'dev/trunk' [ https://svn.apache.org/r1533995 ] SOLR-5042 SOLR-5125 SOLR-5368: mlt.count used incorrectly in MoreLikeThisComponent. > Distributed MoreLikeThis fails with NullPointerException, shard query gives > EarlyTerminatingCollectorException > -- > > Key: SOLR-5125 > URL: https://issues.apache.org/jira/browse/SOLR-5125 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.4 >Reporter: Shawn Heisey > Fix For: 4.6 > > Attachments: SOLR-5125.patch > > > A distributed MoreLikeThis query that works perfectly on 4.2.1 is failing on > 4.4.0. The original query returns a NullPointerException. The Solr log > shows that the shard queries are throwing EarlyTerminatingCollectorException. > Full details to follow in the comments. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5370) Requests to recover when an update fails should be done in background threads.
[ https://issues.apache.org/jira/browse/SOLR-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800262#comment-13800262 ] ASF subversion and git services commented on SOLR-5370: --- Commit 1533996 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1533996 ] SOLR-5370: Requests to recover when an update fails should be done in background threads. > Requests to recover when an update fails should be done in background threads. > -- > > Key: SOLR-5370 > URL: https://issues.apache.org/jira/browse/SOLR-5370 > Project: Solr > Issue Type: Test > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5370.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5370) Requests to recover when an update fails should be done in background threads.
[ https://issues.apache.org/jira/browse/SOLR-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800264#comment-13800264 ] ASF subversion and git services commented on SOLR-5370: --- Commit 1533998 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1533998 ] SOLR-5370: Requests to recover when an update fails should be done in background threads. > Requests to recover when an update fails should be done in background threads. > -- > > Key: SOLR-5370 > URL: https://issues.apache.org/jira/browse/SOLR-5370 > Project: Solr > Issue Type: Test > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5370.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5371) Solr should consistently call SolrServer#shutdown
[ https://issues.apache.org/jira/browse/SOLR-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800269#comment-13800269 ] ASF subversion and git services commented on SOLR-5371: --- Commit 1534002 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1534002 ] SOLR-5371: Solr should consistently call SolrServer#shutdown > Solr should consistently call SolrServer#shutdown > - > > Key: SOLR-5371 > URL: https://issues.apache.org/jira/browse/SOLR-5371 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > It's not always necessary, but we should always do it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5125) Distributed MoreLikeThis fails with NullPointerException, shard query gives EarlyTerminatingCollectorException
[ https://issues.apache.org/jira/browse/SOLR-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800275#comment-13800275 ] ASF subversion and git services commented on SOLR-5125: --- Commit 1534005 from [~elyograg] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534005 ] SOLR-5042 SOLR-5125 SOLR-5368: mlt.count used incorrectly in MoreLikeThisComponent. (merge trunk r1533995) > Distributed MoreLikeThis fails with NullPointerException, shard query gives > EarlyTerminatingCollectorException > -- > > Key: SOLR-5125 > URL: https://issues.apache.org/jira/browse/SOLR-5125 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.4 >Reporter: Shawn Heisey > Fix For: 4.6 > > Attachments: SOLR-5125.patch > > > A distributed MoreLikeThis query that works perfectly on 4.2.1 is failing on > 4.4.0. The original query returns a NullPointerException. The Solr log > shows that the shard queries are throwing EarlyTerminatingCollectorException. > Full details to follow in the comments. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5371) Solr should consistently call SolrServer#shutdown
[ https://issues.apache.org/jira/browse/SOLR-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800271#comment-13800271 ] ASF subversion and git services commented on SOLR-5371: --- Commit 1534003 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534003 ] SOLR-5371: Solr should consistently call SolrServer#shutdown > Solr should consistently call SolrServer#shutdown > - > > Key: SOLR-5371 > URL: https://issues.apache.org/jira/browse/SOLR-5371 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > It's not always necessary, but we should always do it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5371) Solr should consistently call SolrServer#shutdown
[ https://issues.apache.org/jira/browse/SOLR-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800272#comment-13800272 ] ASF subversion and git services commented on SOLR-5371: --- Commit 1534004 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1534004 ] SOLR-5371, SOLR-5370: Add CHANGES entries > Solr should consistently call SolrServer#shutdown > - > > Key: SOLR-5371 > URL: https://issues.apache.org/jira/browse/SOLR-5371 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > It's not always necessary, but we should always do it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5042) MoreLikeThis doesn't return a score when mlt.count is set to 10
[ https://issues.apache.org/jira/browse/SOLR-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800274#comment-13800274 ] ASF subversion and git services commented on SOLR-5042: --- Commit 1534005 from [~elyograg] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534005 ] SOLR-5042 SOLR-5125 SOLR-5368: mlt.count used incorrectly in MoreLikeThisComponent. (merge trunk r1533995) > MoreLikeThis doesn't return a score when mlt.count is set to 10 > --- > > Key: SOLR-5042 > URL: https://issues.apache.org/jira/browse/SOLR-5042 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.3 >Reporter: Josh Curran >Priority: Minor > Attachments: SOLR-5042.patch > > > The problem appears to be around the mlt.count with in the solrconfig.xml. > When this value is set to 10, the 10 values that have been identified as > 'most like this' are returned with the original query, however the 'score' > field is missing. > Changing the mlt.count to say 11 and issuing the same query then the 'score' > field is returned with the same query. This appears to be the workaround. 11 > was just an arbitrary value, 12 or 15 also work > The same problem was raised on stackoverflow > http://stackoverflow.com/questions/16513719/solr-more-like-this-dont-return-score-while-specify-mlt-count -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5370) Requests to recover when an update fails should be done in background threads.
[ https://issues.apache.org/jira/browse/SOLR-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800273#comment-13800273 ] ASF subversion and git services commented on SOLR-5370: --- Commit 1534004 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1534004 ] SOLR-5371, SOLR-5370: Add CHANGES entries > Requests to recover when an update fails should be done in background threads. > -- > > Key: SOLR-5370 > URL: https://issues.apache.org/jira/browse/SOLR-5370 > Project: Solr > Issue Type: Test > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5370.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5368) Morelikethis throw EarlyTerminatingCollectorException,when the document is greater than 5
[ https://issues.apache.org/jira/browse/SOLR-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800276#comment-13800276 ] ASF subversion and git services commented on SOLR-5368: --- Commit 1534005 from [~elyograg] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534005 ] SOLR-5042 SOLR-5125 SOLR-5368: mlt.count used incorrectly in MoreLikeThisComponent. (merge trunk r1533995) > Morelikethis throw EarlyTerminatingCollectorException,when the document is > greater than 5 > - > > Key: SOLR-5368 > URL: https://issues.apache.org/jira/browse/SOLR-5368 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.4 >Reporter: dejie Chang >Priority: Critical > > when i use MoreLikeThisHandler，it throws a EarlyTerminatingCollectorException > when the document is greater than 5. > and I think it is because the fllowing reason in MoreLikeThisComponent.java > NamedList sim = getMoreLikeThese(rb, rb.req.getSearcher(), > rb.getResults().docList, mltcount); > But the actual getMoreLikeThese's The method signature is > NamedList getMoreLikeThese(ResponseBuilder rb, > SolrIndexSearcher searcher, DocList docs, int flags) > so i think the mltcount shoud be flags。 > and also on line 113 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5371) Solr should consistently call SolrServer#shutdown
[ https://issues.apache.org/jira/browse/SOLR-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800278#comment-13800278 ] ASF subversion and git services commented on SOLR-5371: --- Commit 1534006 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534006 ] SOLR-5371, SOLR-5370: Add CHANGES entries > Solr should consistently call SolrServer#shutdown > - > > Key: SOLR-5371 > URL: https://issues.apache.org/jira/browse/SOLR-5371 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > It's not always necessary, but we should always do it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5370) Requests to recover when an update fails should be done in background threads.
[ https://issues.apache.org/jira/browse/SOLR-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800279#comment-13800279 ] ASF subversion and git services commented on SOLR-5370: --- Commit 1534006 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534006 ] SOLR-5371, SOLR-5370: Add CHANGES entries > Requests to recover when an update fails should be done in background threads. > -- > > Key: SOLR-5370 > URL: https://issues.apache.org/jira/browse/SOLR-5370 > Project: Solr > Issue Type: Test > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5370.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800344#comment-13800344 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534021 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534021 ] LUCENE-4956: clean up compound / feature processing a bit (more coming) > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800382#comment-13800382 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534029 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534029 ] LUCENE-4956: more morph cleanups > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800391#comment-13800391 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534030 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534030 ] LUCENE-4956: move dictionary entry classes to dictionary package > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800398#comment-13800398 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534032 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534032 ] LUCENE-4956: don't use wordentry for uncompound processing > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800411#comment-13800411 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534040 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534040 ] LUCENE-4956: don't hold thousands of arrays in dictionary > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800577#comment-13800577 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534115 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534115 ] LUCENE-4956: commit working state > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800602#comment-13800602 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534128 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534128 ] LUCENE-4956: remove trie > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800611#comment-13800611 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534135 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534135 ] LUCENE-4956: Fix file not found case, add close on finally > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800634#comment-13800634 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534141 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534141 ] LUCENE-4956: add some cleanups, remove packing, add missing close, lazy-load compound data until you ask for it > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5274) Teach fast FastVectorHighlighter to highlight "child fields" with parent fields
[ https://issues.apache.org/jira/browse/LUCENE-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800820#comment-13800820 ] ASF subversion and git services commented on LUCENE-5274: - Commit 1534281 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1534281 ] LUCENE-5274: FastVectorHighlighter now supports highlighting against several indexed fields > Teach fast FastVectorHighlighter to highlight "child fields" with parent > fields > --- > > Key: LUCENE-5274 > URL: https://issues.apache.org/jira/browse/LUCENE-5274 > Project: Lucene - Core > Issue Type: Improvement > Components: core/other >Reporter: Nik Everett >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5274.patch > > > I've been messing around with the FastVectorHighlighter and it looks like I > can teach it to highlight matches on "child fields". Like this query: > foo:scissors foo_exact:running > would highlight foo like this: > running with scissors > Where foo is stored WITH_POSITIONS_OFFSETS and foo_plain is an unstored copy > of foo a different analyzer and its own WITH_POSITIONS_OFFSETS. > This would make queries that perform weighted matches against different > analyzers much more convenient to highlight. > I have working code and test cases but they are hacked into Elasticsearch. > I'd love to Lucene-ify if you'll take them. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5274) Teach fast FastVectorHighlighter to highlight "child fields" with parent fields
[ https://issues.apache.org/jira/browse/LUCENE-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800869#comment-13800869 ] ASF subversion and git services commented on LUCENE-5274: - Commit 1534288 from [~jpountz] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534288 ] LUCENE-5274: FastVectorHighlighter now supports highlighting against several indexed fields > Teach fast FastVectorHighlighter to highlight "child fields" with parent > fields > --- > > Key: LUCENE-5274 > URL: https://issues.apache.org/jira/browse/LUCENE-5274 > Project: Lucene - Core > Issue Type: Improvement > Components: core/other >Reporter: Nik Everett >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5274.patch > > > I've been messing around with the FastVectorHighlighter and it looks like I > can teach it to highlight matches on "child fields". Like this query: > foo:scissors foo_exact:running > would highlight foo like this: > running with scissors > Where foo is stored WITH_POSITIONS_OFFSETS and foo_plain is an unstored copy > of foo a different analyzer and its own WITH_POSITIONS_OFFSETS. > This would make queries that perform weighted matches against different > analyzers much more convenient to highlight. > I have working code and test cases but they are hacked into Elasticsearch. > I'd love to Lucene-ify if you'll take them. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801042#comment-13801042 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534364 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534364 ] LUCENE-4956: use a byte1 jamo FST, smaller and much faster > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5294) Suggester Dictionary implementation that takes expressions as term weights
[ https://issues.apache.org/jira/browse/LUCENE-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801358#comment-13801358 ] ASF subversion and git services commented on LUCENE-5294: - Commit 1534430 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1534430 ] LUCENE-5294: simmer down, validate-maven-dependencies > Suggester Dictionary implementation that takes expressions as term weights > -- > > Key: LUCENE-5294 > URL: https://issues.apache.org/jira/browse/LUCENE-5294 > Project: Lucene - Core > Issue Type: New Feature > Components: core/search >Reporter: Areek Zillur > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5294.patch > > > It would be nice to have a Suggester Dictionary implementation that could > compute the weights of the terms consumed by the suggester based on an > user-defined expression (using lucene's expression module). > It could be an extension of the existing DocumentDictionary (which takes > terms, weights and (optionally) payloads from the stored documents in the > index). The only exception being that instead of taking the weights for the > terms from the specified weight fields, it could compute the weights using an > user-defn expression, that uses one or more NumicDocValuesField from the > document. > Example: > let the document have > - product_id > - product_name > - product_popularity > - product_profit > Then this implementation could be used with an expression of > "0.2*product_popularity + 0.8*product_profit" to determine the weights of the > terms for the corresponding documents (optionally along with a payload > (product_id)) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5294) Suggester Dictionary implementation that takes expressions as term weights
[ https://issues.apache.org/jira/browse/LUCENE-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801359#comment-13801359 ] ASF subversion and git services commented on LUCENE-5294: - Commit 1534432 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534432 ] LUCENE-5294: simmer down, validate-maven-dependencies (merged trunk r1534430) > Suggester Dictionary implementation that takes expressions as term weights > -- > > Key: LUCENE-5294 > URL: https://issues.apache.org/jira/browse/LUCENE-5294 > Project: Lucene - Core > Issue Type: New Feature > Components: core/search >Reporter: Areek Zillur > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5294.patch > > > It would be nice to have a Suggester Dictionary implementation that could > compute the weights of the terms consumed by the suggester based on an > user-defined expression (using lucene's expression module). > It could be an extension of the existing DocumentDictionary (which takes > terms, weights and (optionally) payloads from the stored documents in the > index). The only exception being that instead of taking the weights for the > terms from the specified weight fields, it could compute the weights using an > user-defn expression, that uses one or more NumicDocValuesField from the > document. > Example: > let the document have > - product_id > - product_name > - product_popularity > - product_profit > Then this implementation could be used with an expression of > "0.2*product_popularity + 0.8*product_profit" to determine the weights of the > terms for the corresponding documents (optionally along with a payload > (product_id)) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801444#comment-13801444 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534472 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534472 ] LUCENE-4956: do this simpler/faster like kuromoji > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801445#comment-13801445 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534473 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534473 ] LUCENE-4956: pull out broken acronym/etc handling, user can just use classicfilter for that > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801446#comment-13801446 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534477 from [~rcmuir] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534477 ] LUCENE-4956: don't captureState unless we have to > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801543#comment-13801543 ] ASF subversion and git services commented on LUCENE-4956: - Commit 1534514 from [~thetaphi] in branch 'dev/branches/lucene4956' [ https://svn.apache.org/r1534514 ] LUCENE-4956: More optimization on captureState > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5300) Split shards with custom hash ranges
[ https://issues.apache.org/jira/browse/SOLR-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802768#comment-13802768 ] ASF subversion and git services commented on SOLR-5300: --- Commit 1534974 from sha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1534974 ] SOLR-5300: Check that the supplied hash ranges actually cover the entire range of the shard > Split shards with custom hash ranges > > > Key: SOLR-5300 > URL: https://issues.apache.org/jira/browse/SOLR-5300 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 4.6, 5.0 > > Attachments: SOLR-5300-cover-shardrange.patch, SOLR-5300.patch, > SOLR-5300.patch > > > Currently, shards can only be split at the mid point of their hash range. > This makes it difficult to control the distribution of data in the sub shards. > We should make it possible to specify ranges to be used for splitting. A > ranges parameter can be added which can accept hash ranges in hexadecimal > e.g. ranges=0-1f4,1f5-3e8,3e9-5dc will split a shard with range 0-1500 into > three shards with ranges [0,500], [501-1000] and [1001-1500] respectively. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5300) Split shards with custom hash ranges
[ https://issues.apache.org/jira/browse/SOLR-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802769#comment-13802769 ] ASF subversion and git services commented on SOLR-5300: --- Commit 1534975 from sha...@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1534975 ] SOLR-5300: Check that the supplied hash ranges actually cover the entire range of the shard > Split shards with custom hash ranges > > > Key: SOLR-5300 > URL: https://issues.apache.org/jira/browse/SOLR-5300 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 4.6, 5.0 > > Attachments: SOLR-5300-cover-shardrange.patch, SOLR-5300.patch, > SOLR-5300.patch > > > Currently, shards can only be split at the mid point of their hash range. > This makes it difficult to control the distribution of data in the sub shards. > We should make it possible to specify ranges to be used for splitting. A > ranges parameter can be added which can accept hash ranges in hexadecimal > e.g. ranges=0-1f4,1f5-3e8,3e9-5dc will split a shard with range 0-1500 into > three shards with ranges [0,500], [501-1000] and [1001-1500] respectively. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5363) NoClassDefFoundError when using Apache Log4J2
[
https://issues.apache.org/jira/browse/SOLR-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802965#comment-13802965
]
ASF subversion and git services commented on SOLR-5363:
---
Commit 1535065 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1535065 ]
SOLR-5363: Solr doesn't start up properly with Log4J2
> NoClassDefFoundError when using Apache Log4J2
> -
>
> Key: SOLR-5363
> URL: https://issues.apache.org/jira/browse/SOLR-5363
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Petar Tahchiev
>Assignee: Alan Woodward
> Labels: log4j2
> Attachments: SOLR-5363.patch
>
>
> Hey guys,
> I'm using Log4J2 + SLF4J in my project. Unfortunately my embedded solr server
> throws this error when starting:
> {code}
> Caused by: org.springframework.beans.factory.BeanDefinitionStoreException:
> Factory method [public org.springframework.da
> ta.solr.core.SolrOperations
> com.x.platform.core.config.SolrsearchConfig.defaultSolrTemplate() throws
> javax.xml.par
> sers.ParserConfigurationException,java.io.IOException,org.xml.sax.SAXException]
> threw exception; nested exception is org
> .springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'defaultSolrServer' defined in class
> path resource [com/x/platform/core/config/SolrsearchConfig.class]:
> Instantiation of bean failed; nested exception
> is org.springframework.beans.factory.BeanDefinitionStoreException: Factory
> method [public org.apache.solr.client.solrj.
> SolrServer
> com.xx.platform.core.config.SolrsearchConfig.defaultSolrServer() throws
> javax.xml.parsers.ParserConfigur
> ationException,java.io.IOException,org.xml.sax.SAXException] threw exception;
> nested exception is java.lang.NoClassDefFo
> undError: org/apache/log4j/Priority
> at
> org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy
> .java:181)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolv
> er.java:570)
> ... 105 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'defaultSolrServer' de
> fined in class path resource
> [com/xx/platform/core/config/SolrsearchConfig.class]: Instantiation of
> bean failed; ne
> sted exception is
> org.springframework.beans.factory.BeanDefinitionStoreException: Factory
> method [public org.apache.solr
> .client.solrj.SolrServer
> com.xxx.platform.core.config.SolrsearchConfig.defaultSolrServer() throws
> javax.xml.parsers.
> ParserConfigurationException,java.io.IOException,org.xml.sax.SAXException]
> threw exception; nested exception is java.lan
> g.NoClassDefFoundError: org/apache/log4j/Priority
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolv
> er.java:581)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(Ab
> stractAutowireCapableBeanFactory.java:1025)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutow
> ireCapableBeanFactory.java:921)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCap
> ableBeanFactory.java:487)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapab
> leBeanFactory.java:458)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegis
> try.java:223)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at
> org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(Configurati
> onClassEnhancer.java:298)
> at
> com.xx.platform.core.config.SolrsearchConfig$$EnhancerByCGLIB$$c571c5a6.defaultSolrServer()
> at
> com.x.platform.core.config.SolrsearchConfig.defaultSolrTemplate(SolrsearchConfig.java:37)
> at
> com.xx.platform.core.config.SolrsearchConfig$$EnhancerByCGLIB$$c571c5a6.CGLIB$defaultSolrTemplate$2( erated>)
> at
> com.x.platform.core.config.SolrsearchConfig$$EnhancerByCGLIB$$c571c5a6$$FastClassByCGLIB$$f67069c2.invo
> ke()
> at
> org.springframework.cglib.p
[jira] [Commented] (SOLR-5363) NoClassDefFoundError when using Apache Log4J2
[
https://issues.apache.org/jira/browse/SOLR-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802966#comment-13802966
]
ASF subversion and git services commented on SOLR-5363:
---
Commit 1535066 from [~romseygeek] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1535066 ]
SOLR-5363: Solr doesn't start up properly with Log4J2
> NoClassDefFoundError when using Apache Log4J2
> -
>
> Key: SOLR-5363
> URL: https://issues.apache.org/jira/browse/SOLR-5363
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Petar Tahchiev
>Assignee: Alan Woodward
> Labels: log4j2
> Attachments: SOLR-5363.patch
>
>
> Hey guys,
> I'm using Log4J2 + SLF4J in my project. Unfortunately my embedded solr server
> throws this error when starting:
> {code}
> Caused by: org.springframework.beans.factory.BeanDefinitionStoreException:
> Factory method [public org.springframework.da
> ta.solr.core.SolrOperations
> com.x.platform.core.config.SolrsearchConfig.defaultSolrTemplate() throws
> javax.xml.par
> sers.ParserConfigurationException,java.io.IOException,org.xml.sax.SAXException]
> threw exception; nested exception is org
> .springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'defaultSolrServer' defined in class
> path resource [com/x/platform/core/config/SolrsearchConfig.class]:
> Instantiation of bean failed; nested exception
> is org.springframework.beans.factory.BeanDefinitionStoreException: Factory
> method [public org.apache.solr.client.solrj.
> SolrServer
> com.xx.platform.core.config.SolrsearchConfig.defaultSolrServer() throws
> javax.xml.parsers.ParserConfigur
> ationException,java.io.IOException,org.xml.sax.SAXException] threw exception;
> nested exception is java.lang.NoClassDefFo
> undError: org/apache/log4j/Priority
> at
> org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy
> .java:181)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolv
> er.java:570)
> ... 105 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'defaultSolrServer' de
> fined in class path resource
> [com/xx/platform/core/config/SolrsearchConfig.class]: Instantiation of
> bean failed; ne
> sted exception is
> org.springframework.beans.factory.BeanDefinitionStoreException: Factory
> method [public org.apache.solr
> .client.solrj.SolrServer
> com.xxx.platform.core.config.SolrsearchConfig.defaultSolrServer() throws
> javax.xml.parsers.
> ParserConfigurationException,java.io.IOException,org.xml.sax.SAXException]
> threw exception; nested exception is java.lan
> g.NoClassDefFoundError: org/apache/log4j/Priority
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolv
> er.java:581)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(Ab
> stractAutowireCapableBeanFactory.java:1025)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutow
> ireCapableBeanFactory.java:921)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCap
> ableBeanFactory.java:487)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapab
> leBeanFactory.java:458)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegis
> try.java:223)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at
> org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(Configurati
> onClassEnhancer.java:298)
> at
> com.xx.platform.core.config.SolrsearchConfig$$EnhancerByCGLIB$$c571c5a6.defaultSolrServer()
> at
> com.x.platform.core.config.SolrsearchConfig.defaultSolrTemplate(SolrsearchConfig.java:37)
> at
> com.xx.platform.core.config.SolrsearchConfig$$EnhancerByCGLIB$$c571c5a6.CGLIB$defaultSolrTemplate$2( erated>)
> at
> com.x.platform.core.config.SolrsearchConfig$$EnhancerByCGLIB$$c571c5a6$$FastClassByCGLIB$$f67069c2.invo
> ke()
> at
> org.springfram
[jira] [Commented] (SOLR-5380) Using cloudSolrServer.setDefaultCollection(collectionId) does not work as intended for an alias spanning more than 1 collection.
[ https://issues.apache.org/jira/browse/SOLR-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803028#comment-13803028 ] ASF subversion and git services commented on SOLR-5380: --- Commit 1535076 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1535076 ] SOLR-5380: Using cloudSolrServer.setDefaultCollection(collectionId) does not work as intended for an alias spanning more than 1 collection. > Using cloudSolrServer.setDefaultCollection(collectionId) does not work as > intended for an alias spanning more than 1 collection. > > > Key: SOLR-5380 > URL: https://issues.apache.org/jira/browse/SOLR-5380 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5380.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5380) Using cloudSolrServer.setDefaultCollection(collectionId) does not work as intended for an alias spanning more than 1 collection.
[ https://issues.apache.org/jira/browse/SOLR-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803030#comment-13803030 ] ASF subversion and git services commented on SOLR-5380: --- Commit 1535077 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1535077 ] SOLR-5380: Using cloudSolrServer.setDefaultCollection(collectionId) does not work as intended for an alias spanning more than 1 collection. > Using cloudSolrServer.setDefaultCollection(collectionId) does not work as > intended for an alias spanning more than 1 collection. > > > Key: SOLR-5380 > URL: https://issues.apache.org/jira/browse/SOLR-5380 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5380.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5382) Update to Hadoop 2.2 GA release.
[ https://issues.apache.org/jira/browse/SOLR-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803076#comment-13803076 ] ASF subversion and git services commented on SOLR-5382: --- Commit 1535083 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1535083 ] SOLR-5382: Update to Hadoop 2.2 GA release. > Update to Hadoop 2.2 GA release. > > > Key: SOLR-5382 > URL: https://issues.apache.org/jira/browse/SOLR-5382 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5382) Update to Hadoop 2.2 GA release.
[ https://issues.apache.org/jira/browse/SOLR-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803111#comment-13803111 ] ASF subversion and git services commented on SOLR-5382: --- Commit 1535104 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1535104 ] SOLR-5382: Update to Hadoop 2.2 GA release. > Update to Hadoop 2.2 GA release. > > > Key: SOLR-5382 > URL: https://issues.apache.org/jira/browse/SOLR-5382 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5303) OrdinalsCache should use reader.getCoreCacheKey()
[ https://issues.apache.org/jira/browse/LUCENE-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803293#comment-13803293 ] ASF subversion and git services commented on LUCENE-5303: - Commit 1535163 from [~shaie] in branch 'dev/trunk' [ https://svn.apache.org/r1535163 ] LUCENE-5303: OrdinalsCache should use reader.getCoreCacheKey() > OrdinalsCache should use reader.getCoreCacheKey() > - > > Key: LUCENE-5303 > URL: https://issues.apache.org/jira/browse/LUCENE-5303 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5303.patch > > > I'm doing some facet performance tests, and I tried using the > CachedOrdsCountingFacetsAggregator to cache the decoded ords per doc X field > ... but noticed it was generating way too many cache entries, because it's > currently using the NDV instance as the cache key. > NDV instances are thread-private so this results in way too many entries in > the cache. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5303) OrdinalsCache should use reader.getCoreCacheKey()
[ https://issues.apache.org/jira/browse/LUCENE-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803299#comment-13803299 ] ASF subversion and git services commented on LUCENE-5303: - Commit 1535167 from [~shaie] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1535167 ] LUCENE-5303: OrdinalsCache should use reader.getCoreCacheKey() > OrdinalsCache should use reader.getCoreCacheKey() > - > > Key: LUCENE-5303 > URL: https://issues.apache.org/jira/browse/LUCENE-5303 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5303.patch > > > I'm doing some facet performance tests, and I tried using the > CachedOrdsCountingFacetsAggregator to cache the decoded ords per doc X field > ... but noticed it was generating way too many cache entries, because it's > currently using the NDV instance as the cache key. > NDV instances are thread-private so this results in way too many entries in > the cache. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5382) Update to Hadoop 2.2 GA release.
[ https://issues.apache.org/jira/browse/SOLR-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803441#comment-13803441 ] ASF subversion and git services commented on SOLR-5382: --- Commit 1535195 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1535195 ] SOLR-5382: Update protobuf checksum > Update to Hadoop 2.2 GA release. > > > Key: SOLR-5382 > URL: https://issues.apache.org/jira/browse/SOLR-5382 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5382) Update to Hadoop 2.2 GA release.
[ https://issues.apache.org/jira/browse/SOLR-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803443#comment-13803443 ] ASF subversion and git services commented on SOLR-5382: --- Commit 1535197 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1535197 ] SOLR-5382: Update protobuf checksum > Update to Hadoop 2.2 GA release. > > > Key: SOLR-5382 > URL: https://issues.apache.org/jira/browse/SOLR-5382 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5384) randomlyEnableAutoSoftCommit in ChaosMonkeySafeLeaderTest is buggy.
[ https://issues.apache.org/jira/browse/SOLR-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803479#comment-13803479 ] ASF subversion and git services commented on SOLR-5384: --- Commit 1535204 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1535204 ] SOLR-5384: randomlyEnableAutoSoftCommit in ChaosMonkeySafeLeaderTest is buggy. > randomlyEnableAutoSoftCommit in ChaosMonkeySafeLeaderTest is buggy. > --- > > Key: SOLR-5384 > URL: https://issues.apache.org/jira/browse/SOLR-5384 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5384.patch > > > It only turns on NRT for shard1. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5384) randomlyEnableAutoSoftCommit in ChaosMonkeySafeLeaderTest is buggy.
[ https://issues.apache.org/jira/browse/SOLR-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803482#comment-13803482 ] ASF subversion and git services commented on SOLR-5384: --- Commit 1535205 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1535205 ] SOLR-5384: randomlyEnableAutoSoftCommit in ChaosMonkeySafeLeaderTest is buggy. > randomlyEnableAutoSoftCommit in ChaosMonkeySafeLeaderTest is buggy. > --- > > Key: SOLR-5384 > URL: https://issues.apache.org/jira/browse/SOLR-5384 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: SOLR-5384.patch > > > It only turns on NRT for shard1. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5027) Field Collapsing PostFilter
[
https://issues.apache.org/jira/browse/SOLR-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803532#comment-13803532
]
ASF subversion and git services commented on SOLR-5027:
---
Commit 1535208 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1535208 ]
SOLR-5027 CollapsingQParserPlugin
> Field Collapsing PostFilter
> ---
>
> Key: SOLR-5027
> URL: https://issues.apache.org/jira/browse/SOLR-5027
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch
>
>
> This ticket introduces the *CollapsingQParserPlugin*
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
> This is a high performance alternative to standard Solr field collapsing
> (with *ngroups*) when the number of distinct groups in the result set is high.
> For example in one performance test, a search with 10 million full results
> and 1 million collapsed groups:
> Standard grouping with ngroups : 17 seconds.
> CollapsingQParserPlugin: 300 milli-seconds.
> Sample syntax:
> Collapse based on the highest scoring document:
> {code}
> fq=(!collapse field=}
> {code}
> Collapse based on the min value of a numeric field:
> {code}
> fq={!collapse field= min=}
> {code}
> Collapse based on the max value of a numeric field:
> {code}
> fq={!collapse field= max=}
> {code}
> Collapse with a null policy:
> {code}
> fq={!collapse field= nullPolicy=}
> {code}
> There are three null policies:
> ignore : removes docs with a null value in the collapse field (default).
> expand : treats each doc with a null value in the collapse field as a
> separate group.
> collapse : collapses all docs with a null value into a single group using
> either highest score, or min/max.
> The CollapsingQParserPlugin also fully supports the QueryElevationComponent
> *Note:* The July 16 patch also includes and ExpandComponent that expands the
> collapsed groups for the current search result page. This functionality will
> be moved to it's own ticket.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5303) OrdinalsCache should use reader.getCoreCacheKey()
[ https://issues.apache.org/jira/browse/LUCENE-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803577#comment-13803577 ] ASF subversion and git services commented on LUCENE-5303: - Commit 1535215 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1535215 ] LUCENE-5303: clear cache before each test > OrdinalsCache should use reader.getCoreCacheKey() > - > > Key: LUCENE-5303 > URL: https://issues.apache.org/jira/browse/LUCENE-5303 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Reporter: Michael McCandless >Assignee: Shai Erera > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5303.patch > > > I'm doing some facet performance tests, and I tried using the > CachedOrdsCountingFacetsAggregator to cache the decoded ords per doc X field > ... but noticed it was generating way too many cache entries, because it's > currently using the NDV instance as the cache key. > NDV instances are thread-private so this results in way too many entries in > the cache. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
