[jira] [Assigned] (SOLR-2834) AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter
[ https://issues.apache.org/jira/browse/SOLR-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned SOLR-2834: --- Assignee: (was: Uwe Schindler) Sorry this is not a bug caused by me, as it affects only SolrJ. I have no idea what needs to be done to fix this correctly. The server part is fine. AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter - Key: SOLR-2834 URL: https://issues.apache.org/jira/browse/SOLR-2834 Project: Solr Issue Type: Bug Components: clients - java, Schema and Analysis Affects Versions: 3.4 Reporter: Shane When using FieldAnalysisRequest.java to analysis a field, a ClassCastExcpetion is thrown if the schema defines the filter org.apache.solr.analysis.HTMLStripCharFilter. The exception is: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.List at org.apache.solr.client.solrj.response.AnalysisResponseBase.buildPhases(AnalysisResponseBase.java:69) at org.apache.solr.client.solrj.response.FieldAnalysisResponse.setResponse(FieldAnalysisResponse.java:66) at org.apache.solr.client.solrj.request.FieldAnalysisRequest.process(FieldAnalysisRequest.java:107) My schema definition is: fieldType name=text class=solr.TextField positionIncrementGap=100 analyzer charFilter class=solr.HTMLStripCharFilterFactory / tokenizer class=solr.StandardTokenizerFactory / filter class=solr.StandardFilterFactory / filter class=solr.TrimFilterFactory / filter class=solr.LowerCaseFilterFactory / /analyzer /fieldType The response is part is: lst name=query str name=org.apache.solr.analysis.HTMLStripCharFiltertesting analysis/str arr name=org.apache.lucene.analysis.standard.StandardTokenizer lst... A simplistic fix would be to test if the Entry value is an instance of List. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2834) AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter
[ https://issues.apache.org/jira/browse/SOLR-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-2834: Component/s: clients - java Fix Version/s: (was: 3.5) (was: 4.0) AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter - Key: SOLR-2834 URL: https://issues.apache.org/jira/browse/SOLR-2834 Project: Solr Issue Type: Bug Components: clients - java, Schema and Analysis Affects Versions: 3.4 Reporter: Shane When using FieldAnalysisRequest.java to analysis a field, a ClassCastExcpetion is thrown if the schema defines the filter org.apache.solr.analysis.HTMLStripCharFilter. The exception is: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.List at org.apache.solr.client.solrj.response.AnalysisResponseBase.buildPhases(AnalysisResponseBase.java:69) at org.apache.solr.client.solrj.response.FieldAnalysisResponse.setResponse(FieldAnalysisResponse.java:66) at org.apache.solr.client.solrj.request.FieldAnalysisRequest.process(FieldAnalysisRequest.java:107) My schema definition is: fieldType name=text class=solr.TextField positionIncrementGap=100 analyzer charFilter class=solr.HTMLStripCharFilterFactory / tokenizer class=solr.StandardTokenizerFactory / filter class=solr.StandardFilterFactory / filter class=solr.TrimFilterFactory / filter class=solr.LowerCaseFilterFactory / /analyzer /fieldType The response is part is: lst name=query str name=org.apache.solr.analysis.HTMLStripCharFiltertesting analysis/str arr name=org.apache.lucene.analysis.standard.StandardTokenizer lst... A simplistic fix would be to test if the Entry value is an instance of List. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1926) add hl.q parameter
[
https://issues.apache.org/jira/browse/SOLR-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128126#comment-13128126
]
Ukyo Virgden commented on SOLR-1926:
Hi everyone,
What's the status of this issue? Have you found and workarounds?
add hl.q parameter
--
Key: SOLR-1926
URL: https://issues.apache.org/jira/browse/SOLR-1926
Project: Solr
Issue Type: Improvement
Components: highlighter
Affects Versions: 1.4
Reporter: Koji Sekiguchi
Priority: Trivial
If hl.q parameter is set, HighlightComponent uses it rather than q.
Use case:
You search PC with highlight and facet capability:
{code}
q=PC
facet=onfacet.field=makerfacet.field=something
hl=onhl.fl=desc
{code}
You get a lot of results with snippets (term PC highlighted in desc field).
Then you click a link maker:DELL(50) to narrow the result:
{code}
q=PC
facet=onfacet.field=something
fq=maker:DELL
hl=onhl.fl=desc
{code}
You'll get narrowed result with term PC highlighted snippets. But,
sometimes I'd like to see DELL to be highlighted as well, because I clicked
DELL. In this case, hl.q can be used:
{code}
q=PC
facet=onfacet.field=something
fq=maker:DELL
hl=onhl.fl=desc*hl.q=PC+maker:DELL*
{code}
Note that hl.requireFieldMatch should be false (false is default) in this
scenario.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1926) add hl.q parameter
[
https://issues.apache.org/jira/browse/SOLR-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128129#comment-13128129
]
Ukyo Virgden commented on SOLR-1926:
Hoss: Having a look at the highlight component I see that the Lucene
highlighters require a FieldQuery. Although hl.text params makes much more
sense, it seams to keep a Query object in response builder makes sense. From
what I see in the code, I think set/getHighlightQuery() should not be in
QParser. Anyway, setting highlight query of response builder during query
preperation might do the trick.
add hl.q parameter
--
Key: SOLR-1926
URL: https://issues.apache.org/jira/browse/SOLR-1926
Project: Solr
Issue Type: Improvement
Components: highlighter
Affects Versions: 1.4
Reporter: Koji Sekiguchi
Priority: Trivial
If hl.q parameter is set, HighlightComponent uses it rather than q.
Use case:
You search PC with highlight and facet capability:
{code}
q=PC
facet=onfacet.field=makerfacet.field=something
hl=onhl.fl=desc
{code}
You get a lot of results with snippets (term PC highlighted in desc field).
Then you click a link maker:DELL(50) to narrow the result:
{code}
q=PC
facet=onfacet.field=something
fq=maker:DELL
hl=onhl.fl=desc
{code}
You'll get narrowed result with term PC highlighted snippets. But,
sometimes I'd like to see DELL to be highlighted as well, because I clicked
DELL. In this case, hl.q can be used:
{code}
q=PC
facet=onfacet.field=something
fq=maker:DELL
hl=onhl.fl=desc*hl.q=PC+maker:DELL*
{code}
Note that hl.requireFieldMatch should be false (false is default) in this
scenario.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-1926) add hl.q parameter
[
https://issues.apache.org/jira/browse/SOLR-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128129#comment-13128129
]
Ukyo Virgden edited comment on SOLR-1926 at 10/15/11 10:31 AM:
---
Hoss: Having a look at the highlight component I see that the Lucene
highlighters require a FieldQuery. Although hl.text params makes much more
sense, it seams to keep a Query object in response builder would be easier.
From what I see in the code, I think set/getHighlightQuery() should not be in
QParser. Anyway, setting highlight query of response builder during query
preperation might do the trick.
was (Author: ukyo):
Hoss: Having a look at the highlight component I see that the Lucene
highlighters require a FieldQuery. Although hl.text params makes much more
sense, it seams to keep a Query object in response builder makes sense. From
what I see in the code, I think set/getHighlightQuery() should not be in
QParser. Anyway, setting highlight query of response builder during query
preperation might do the trick.
add hl.q parameter
--
Key: SOLR-1926
URL: https://issues.apache.org/jira/browse/SOLR-1926
Project: Solr
Issue Type: Improvement
Components: highlighter
Affects Versions: 1.4
Reporter: Koji Sekiguchi
Priority: Trivial
If hl.q parameter is set, HighlightComponent uses it rather than q.
Use case:
You search PC with highlight and facet capability:
{code}
q=PC
facet=onfacet.field=makerfacet.field=something
hl=onhl.fl=desc
{code}
You get a lot of results with snippets (term PC highlighted in desc field).
Then you click a link maker:DELL(50) to narrow the result:
{code}
q=PC
facet=onfacet.field=something
fq=maker:DELL
hl=onhl.fl=desc
{code}
You'll get narrowed result with term PC highlighted snippets. But,
sometimes I'd like to see DELL to be highlighted as well, because I clicked
DELL. In this case, hl.q can be used:
{code}
q=PC
facet=onfacet.field=something
fq=maker:DELL
hl=onhl.fl=desc*hl.q=PC+maker:DELL*
{code}
Note that hl.requireFieldMatch should be false (false is default) in this
scenario.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3520) If the NRT reader hasn't changed then IndexReader.openIfChanged should return null
If the NRT reader hasn't changed then IndexReader.openIfChanged should return
null
--
Key: LUCENE-3520
URL: https://issues.apache.org/jira/browse/LUCENE-3520
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.5, 4.0
I hit a failure in TestSearcherManager (NOTE: doesn't always fail):
{noformat}
ant test -Dtestcase=TestSearcherManager -Dtestmethod=testSearcherManager
-Dtests.seed=459ac99a4256789c:-29b8a7f52497c3b4:145ae632ae9e1ecf
{noformat}
It was tripping the assert inside SearcherLifetimeManager.record,
because two different IndexSearcher instances had different IR
instances sharing the same version. This was happening because
IW.getReader always returns a new reader even when there are no
changes. I think we should fix that...
Separately I found a deadlock in
TestSearcherManager.testIntermediateClose, if the test gets
SerialMergeScheduler and needs to merge during the second commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3520) If the NRT reader hasn't changed then IndexReader.openIfChanged should return null
[
https://issues.apache.org/jira/browse/LUCENE-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-3520:
---
Attachment: LUCENE-3520.patch
Patch.
If the NRT reader hasn't changed then IndexReader.openIfChanged should return
null
--
Key: LUCENE-3520
URL: https://issues.apache.org/jira/browse/LUCENE-3520
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.5, 4.0
Attachments: LUCENE-3520.patch
I hit a failure in TestSearcherManager (NOTE: doesn't always fail):
{noformat}
ant test -Dtestcase=TestSearcherManager -Dtestmethod=testSearcherManager
-Dtests.seed=459ac99a4256789c:-29b8a7f52497c3b4:145ae632ae9e1ecf
{noformat}
It was tripping the assert inside SearcherLifetimeManager.record,
because two different IndexSearcher instances had different IR
instances sharing the same version. This was happening because
IW.getReader always returns a new reader even when there are no
changes. I think we should fix that...
Separately I found a deadlock in
TestSearcherManager.testIntermediateClose, if the test gets
SerialMergeScheduler and needs to merge during the second commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1536) if a filter can support random access API, we should use it
[ https://issues.apache.org/jira/browse/LUCENE-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128209#comment-13128209 ] Michael McCandless commented on LUCENE-1536: bq. Mike: Normal Filters always respect acceptDocs, as they generally use the acceptDocs to pass them to IndexReader. OK this makes sense (that many filter impls will need to pass through the accept docs down to eventual enums). So I think the API change is good! bq. The optimizations for CachingWrapperFilter to also cache acceptDocs should maybe done in a separate issue. We have currently no slowdown, as its still faster than before. Improvements can come later. OK we can add it back under a new issue after committing this; but I think it's important to not lose this (CachingWrapperFilter today is able to pre-AND the liveDocs and cache that). It sounds like the cache key just has to become a pair of reader and identity(acceptDocs), but we should only cache when acceptDocs == reader.getLiveDocs, else we can easily over-cache if in the future we pass more interesting acceptDocs down. Great! if a filter can support random access API, we should use it --- Key: LUCENE-1536 URL: https://issues.apache.org/jira/browse/LUCENE-1536 Project: Lucene - Java Issue Type: Improvement Components: core/search Affects Versions: 2.4 Reporter: Michael McCandless Assignee: Michael McCandless Priority: Minor Labels: gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: CachedFilterIndexReader.java, LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536_hack.patch, changes-yonik-uwe.patch, luceneutil.patch I ran some performance tests, comparing applying a filter via random-access API instead of current trunk's iterator API. This was inspired by LUCENE-1476, where we realized deletions should really be implemented just like a filter, but then in testing found that switching deletions to iterator was a very sizable performance hit. Some notes on the test: * Index is first 2M docs of Wikipedia. Test machine is Mac OS X 10.5.6, quad core Intel CPU, 6 GB RAM, java 1.6.0_07-b06-153. * I test across multiple queries. 1-X means an OR query, eg 1-4 means 1 OR 2 OR 3 OR 4, whereas +1-4 is an AND query, ie 1 AND 2 AND 3 AND 4. u s means united states (phrase search). * I test with multiple filter densities (0, 1, 2, 5, 10, 25, 75, 90, 95, 98, 99, 99.9 (filter is non-null but all bits are set), 100 (filter=null, control)). * Method high means I use random-access filter API in IndexSearcher's main loop. Method low means I use random-access filter API down in SegmentTermDocs (just like deleted docs today). * Baseline (QPS) is current trunk, where filter is applied as iterator up high (ie in IndexSearcher's search loop). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3521) upgrade icu jar to 4.8.1.1 / remove lucenetestcase hack
upgrade icu jar to 4.8.1.1 / remove lucenetestcase hack --- Key: LUCENE-3521 URL: https://issues.apache.org/jira/browse/LUCENE-3521 Project: Lucene - Java Issue Type: Improvement Reporter: Robert Muir Fix For: 3.5, 4.0 Attachments: LUCENE-3521.patch This bug fix release fixes problems with icu under java7: http://bugs.icu-project.org/trac/ticket/8734 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2836) maven compilation error - symbol not found - ShardFieldSortedHitQueue
maven compilation error - symbol not found - ShardFieldSortedHitQueue - Key: SOLR-2836 URL: https://issues.apache.org/jira/browse/SOLR-2836 Project: Solr Issue Type: Bug Components: Build Affects Versions: 4.0 Reporter: Ukyo Virgden maven building fails at several point due to organization of tests however even when you bypass test compilation, you get symbol not found error in QueryComponent.java. The reason is that the ShardFieldSortedHitQueue is a class defined in ShardDoc. class cannot be found during maven compilation although they're under the same package. Workaroud: if you promote ShardFieldSortedHitQueue to be public, and put it in a file of its own, maven compilation goes well. There seems to be several boundary problems within core and solrj packages about the tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2836) maven compilation error - symbol not found - ShardFieldSortedHitQueue
[ https://issues.apache.org/jira/browse/SOLR-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128245#comment-13128245 ] Ukyo Virgden commented on SOLR-2836: steps to reproduce * svn update * ant get-maven-poms * mvn -N -Pbootstrap install * mvn install -Dmaven.test.skip=true maven compilation error - symbol not found - ShardFieldSortedHitQueue - Key: SOLR-2836 URL: https://issues.apache.org/jira/browse/SOLR-2836 Project: Solr Issue Type: Bug Components: Build Affects Versions: 4.0 Reporter: Ukyo Virgden Labels: core, maven maven building fails at several point due to organization of tests however even when you bypass test compilation, you get symbol not found error in QueryComponent.java. The reason is that the ShardFieldSortedHitQueue is a class defined in ShardDoc. class cannot be found during maven compilation although they're under the same package. Workaroud: if you promote ShardFieldSortedHitQueue to be public, and put it in a file of its own, maven compilation goes well. There seems to be several boundary problems within core and solrj packages about the tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2835) Compilation problem with maven - package org.apache.solr.core does not exist
[
https://issues.apache.org/jira/browse/SOLR-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128275#comment-13128275
]
Steven Rowe commented on SOLR-2835:
---
Hi Ukyo,
I don't see the problems you report when I build trunk under Maven v2.2.1.
What version of Maven are you using? Are you running {{mvn test}} in the
{{solr/}} directory?
FYI, under maven, the solrj test sources don't get compiled or run as part of
the solrj module. Instead, they are compiled and run with the solr core
module, because Maven's dependency system can't directly handle the unusual
dependencies between solrj, solr core, and the solr test framework. (solr core
has a non-test dependency on solrj; solr test framework has a non-test
dependency on solr core; and both solr core and solrj have a test dependency on
the solr test framework.)
Another FYI: the maven build is run nightly under Jenkins - see
[http://wiki.apache.org/solr/NightlyBuilds].
In the future, this kind of issue is best discussed on the solr-user mailing
list before making a JIRA issue.
Compilation problem with maven - package org.apache.solr.core does not exist
Key: SOLR-2835
URL: https://issues.apache.org/jira/browse/SOLR-2835
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Ukyo Virgden
Labels: maven, solrj
maven compilation fails.
Steps to reproduce are;
* svn update
* ant get-maven-poms
* mvn -N -Pbootstrap install
* mvn -DskipTests install
Build works until solrj test compilation Here's the start of the errors.
{code}
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
solr-solrj ---
[INFO] Compiling 157 source files to
/users/ukyo/lucene-solr/solr/build/solr-solrj/classes/test
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/users/ukyo/lucene-solr/solr/solrj/src/test/org/apache/solr/client/solrj/embedded/MergeIndexesEmbeddedTest.java:[24,27]
package org.apache.solr.core does not exist
[ERROR]
/users/ukyo/lucene-solr/solr/solrj/src/test/org/apache/solr/client/solrj/MergeIndexesExampleTestBase.java:[28,27]
package org.apache.solr.core does not exist
[ERROR]
/users/ukyo/lucene-solr/solr/solrj/src/test/org/apache/solr/client/solrj/MergeIndexesExampleTestBase.java:[29,27]
package org.apache.solr.core does not exist
[ERROR]
/users/ukyo/lucene-solr/solr/solrj/src/test/org/apache/solr/client/solrj/MergeIndexesExampleTestBase.java:[30,27]
package org.apache.solr.util does not exist
[ERROR]
/users/ukyo/lucene-solr/solr/solrj/src/test/org/apache/solr/client/solrj/SolrExampleTestBase.java:[21,27]
package org.apache.solr.util does not exist
[ERROR]
/users/ukyo/lucene-solr/solr/solrj/src/test/org/apache/solr/client/solrj/SolrExampleTestBase.java:[31,50]
cannot find symbol
{code}
All following errors are the same package not found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2836) maven compilation error - symbol not found - ShardFieldSortedHitQueue
[ https://issues.apache.org/jira/browse/SOLR-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved SOLR-2836. --- Resolution: Duplicate Assignee: Steven Rowe See my comments on SOLR-2835, which is symptomatic of the same problem(s) underlying this issue. maven compilation error - symbol not found - ShardFieldSortedHitQueue - Key: SOLR-2836 URL: https://issues.apache.org/jira/browse/SOLR-2836 Project: Solr Issue Type: Bug Components: Build Affects Versions: 4.0 Reporter: Ukyo Virgden Assignee: Steven Rowe Labels: core, maven maven building fails at several point due to organization of tests however even when you bypass test compilation, you get symbol not found error in QueryComponent.java. The reason is that the ShardFieldSortedHitQueue is a class defined in ShardDoc. class cannot be found during maven compilation although they're under the same package. Workaroud: if you promote ShardFieldSortedHitQueue to be public, and put it in a file of its own, maven compilation goes well. There seems to be several boundary problems within core and solrj packages about the tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3520) If the NRT reader hasn't changed then IndexReader.openIfChanged should return null
[
https://issues.apache.org/jira/browse/LUCENE-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128283#comment-13128283
]
Yonik Seeley commented on LUCENE-3520:
--
Steve just took a stack trace (and aborted the build) of a test run started
yesterday.
I noticed SearchManager in one of the traces. Maybe this issue fixes?
https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/10840/console
If the NRT reader hasn't changed then IndexReader.openIfChanged should return
null
--
Key: LUCENE-3520
URL: https://issues.apache.org/jira/browse/LUCENE-3520
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.5, 4.0
Attachments: LUCENE-3520.patch
I hit a failure in TestSearcherManager (NOTE: doesn't always fail):
{noformat}
ant test -Dtestcase=TestSearcherManager -Dtestmethod=testSearcherManager
-Dtests.seed=459ac99a4256789c:-29b8a7f52497c3b4:145ae632ae9e1ecf
{noformat}
It was tripping the assert inside SearcherLifetimeManager.record,
because two different IndexSearcher instances had different IR
instances sharing the same version. This was happening because
IW.getReader always returns a new reader even when there are no
changes. I think we should fix that...
Separately I found a deadlock in
TestSearcherManager.testIntermediateClose, if the test gets
SerialMergeScheduler and needs to merge during the second commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2823) Re-use of UpdateProcessor configurations in multiple UpdateChains
[ https://issues.apache.org/jira/browse/SOLR-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128286#comment-13128286 ] Hoss Man commented on SOLR-2823: bq. I think (optinally) named processors are a more direct solution. Think of the named processors as processor configs, not necessarily 1:1 with Java objects. When instansiating the crawl chain we'd simply fetch the config from the referenced element instead of inline. It may still have a distinct solr.LanguageIdentifierUpdateProcessorFactory class instance from the cms pipeline. To be clear: i wasn't arguing that the subchain syntax i suggested would be 1:1 with java objects either, it could work exactly as you intend named processors to work (ie: pure syntactic sugar). my suggestions was just that if we allow subchain by reference type configuration, it would achieve everything you describe using named processors (because you could have a sub-chain containing a single processor) _and_ it would handle the common case of chains that have a lot in common, but do some extra stuff at the beginning/end. bq. Sub chains may also come in handy for some situations, but that could be handled separately later, if needed. Eh .. i guess .. but it seems like it would be less total work to just do subchains and let people use chains of one processor to deal with the reusing individual processor configs usecase(s). (FWIW: Don't let my comments stop/dissuade you, either way would be a huge improvement over what we've got now ... i just wanted to point out something that seemed like more bang for the buck) Re-use of UpdateProcessor configurations in multiple UpdateChains - Key: SOLR-2823 URL: https://issues.apache.org/jira/browse/SOLR-2823 Project: Solr Issue Type: Improvement Components: update Reporter: Jan Høydahl Priority: Minor When dealing with multiple UpdateChains and Processors, you frequently need to re-use configuration. Two chains may be equal except for one config setting in one processor. I propose to allow named processor configs, which can be referenced by name in the chains. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3521) upgrade icu jar to 4.8.1.1 / remove lucenetestcase hack
[ https://issues.apache.org/jira/browse/LUCENE-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-3521. - Resolution: Fixed upgrade icu jar to 4.8.1.1 / remove lucenetestcase hack --- Key: LUCENE-3521 URL: https://issues.apache.org/jira/browse/LUCENE-3521 Project: Lucene - Java Issue Type: Improvement Reporter: Robert Muir Fix For: 3.5, 4.0 Attachments: LUCENE-3521.patch This bug fix release fixes problems with icu under java7: http://bugs.icu-project.org/trac/ticket/8734 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3520) If the NRT reader hasn't changed then IndexReader.openIfChanged should return null
[
https://issues.apache.org/jira/browse/LUCENE-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128290#comment-13128290
]
Simon Willnauer commented on LUCENE-3520:
-
bq.It should still be opening an NRT reader: if you have an NRT reader (which
we do here) and pass that to IR.openIfChanged, you'll always get back a new NRT
reader (this is the contract of IR.openIfChanged).
hmm, however the signature of openIfChanged(IR, boolean) actually referes to
openIfChanged(IndexReader oldReader, boolean readonly) which seems confusing
when you pass applyDeletes to it, no?
If the NRT reader hasn't changed then IndexReader.openIfChanged should return
null
--
Key: LUCENE-3520
URL: https://issues.apache.org/jira/browse/LUCENE-3520
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.5, 4.0
Attachments: LUCENE-3520.patch
I hit a failure in TestSearcherManager (NOTE: doesn't always fail):
{noformat}
ant test -Dtestcase=TestSearcherManager -Dtestmethod=testSearcherManager
-Dtests.seed=459ac99a4256789c:-29b8a7f52497c3b4:145ae632ae9e1ecf
{noformat}
It was tripping the assert inside SearcherLifetimeManager.record,
because two different IndexSearcher instances had different IR
instances sharing the same version. This was happening because
IW.getReader always returns a new reader even when there are no
changes. I think we should fix that...
Separately I found a deadlock in
TestSearcherManager.testIntermediateClose, if the test gets
SerialMergeScheduler and needs to merge during the second commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3520) If the NRT reader hasn't changed then IndexReader.openIfChanged should return null
[
https://issues.apache.org/jira/browse/LUCENE-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128298#comment-13128298
]
Michael McCandless commented on LUCENE-3520:
bq. I noticed SearchManager in one of the traces. Maybe this issue fixes?
Indeed I think this fixes it; I just committed that test-only fix.
If the NRT reader hasn't changed then IndexReader.openIfChanged should return
null
--
Key: LUCENE-3520
URL: https://issues.apache.org/jira/browse/LUCENE-3520
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.5, 4.0
Attachments: LUCENE-3520.patch
I hit a failure in TestSearcherManager (NOTE: doesn't always fail):
{noformat}
ant test -Dtestcase=TestSearcherManager -Dtestmethod=testSearcherManager
-Dtests.seed=459ac99a4256789c:-29b8a7f52497c3b4:145ae632ae9e1ecf
{noformat}
It was tripping the assert inside SearcherLifetimeManager.record,
because two different IndexSearcher instances had different IR
instances sharing the same version. This was happening because
IW.getReader always returns a new reader even when there are no
changes. I think we should fix that...
Separately I found a deadlock in
TestSearcherManager.testIntermediateClose, if the test gets
SerialMergeScheduler and needs to merge during the second commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3520) If the NRT reader hasn't changed then IndexReader.openIfChanged should return null
[
https://issues.apache.org/jira/browse/LUCENE-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128299#comment-13128299
]
Michael McCandless commented on LUCENE-3520:
bq. hmm, however the signature of openIfChanged(IR, boolean) actually referes
to openIfChanged(IndexReader oldReader, boolean readonly) which seems confusing
when you pass applyDeletes to it, no?
Ugh, you're right!
In fact we don't need to pass applyDeletes either; this too is inherited from
the prior reader. So I'll just reduce it to IR.openIfChanged(oldReader). Hmm
then we can simplify SearcherManager some. I'll work out a new patch.
If the NRT reader hasn't changed then IndexReader.openIfChanged should return
null
--
Key: LUCENE-3520
URL: https://issues.apache.org/jira/browse/LUCENE-3520
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.5, 4.0
Attachments: LUCENE-3520.patch
I hit a failure in TestSearcherManager (NOTE: doesn't always fail):
{noformat}
ant test -Dtestcase=TestSearcherManager -Dtestmethod=testSearcherManager
-Dtests.seed=459ac99a4256789c:-29b8a7f52497c3b4:145ae632ae9e1ecf
{noformat}
It was tripping the assert inside SearcherLifetimeManager.record,
because two different IndexSearcher instances had different IR
instances sharing the same version. This was happening because
IW.getReader always returns a new reader even when there are no
changes. I think we should fix that...
Separately I found a deadlock in
TestSearcherManager.testIntermediateClose, if the test gets
SerialMergeScheduler and needs to merge during the second commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-3.x - Build # 520 - Failure
Build: https://builds.apache.org/job/Lucene-3.x/520/ 3 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterExceptions.testRollbackExceptionHang Error Message: did not hit intentional RuntimeException Stack Trace: junit.framework.AssertionFailedError: did not hit intentional RuntimeException at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.apache.lucene.index.TestIndexWriterExceptions.testRollbackExceptionHang(TestIndexWriterExceptions.java:950) at org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java:418) REGRESSION: org.apache.lucene.index.TestIndexWriterExceptions.testExceptionOnMergeInit Error Message: null Stack Trace: junit.framework.AssertionFailedError: at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.apache.lucene.index.TestIndexWriterExceptions.testExceptionOnMergeInit(TestIndexWriterExceptions.java:392) at org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java:418) REGRESSION: org.apache.lucene.index.TestIndexWriterExceptions.testExceptionDocumentsWriterInit Error Message: did not hit exception Stack Trace: junit.framework.AssertionFailedError: did not hit exception at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.apache.lucene.index.TestIndexWriterExceptions.testExceptionDocumentsWriterInit(TestIndexWriterExceptions.java:312) at org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java:418) Build Log (for compile errors): [...truncated 14980 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3520) If the NRT reader hasn't changed then IndexReader.openIfChanged should return null
[
https://issues.apache.org/jira/browse/LUCENE-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-3520:
---
Attachment: LUCENE-3520.patch
New patch; I was able to simplify SearcherManager since both cases
(open-from-writer (= NRT case) and open-from-dir (= non-NRT case)) now call the
same IR.openIfChanged(oldReader).
If the NRT reader hasn't changed then IndexReader.openIfChanged should return
null
--
Key: LUCENE-3520
URL: https://issues.apache.org/jira/browse/LUCENE-3520
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.5, 4.0
Attachments: LUCENE-3520.patch, LUCENE-3520.patch
I hit a failure in TestSearcherManager (NOTE: doesn't always fail):
{noformat}
ant test -Dtestcase=TestSearcherManager -Dtestmethod=testSearcherManager
-Dtests.seed=459ac99a4256789c:-29b8a7f52497c3b4:145ae632ae9e1ecf
{noformat}
It was tripping the assert inside SearcherLifetimeManager.record,
because two different IndexSearcher instances had different IR
instances sharing the same version. This was happening because
IW.getReader always returns a new reader even when there are no
changes. I think we should fix that...
Separately I found a deadlock in
TestSearcherManager.testIntermediateClose, if the test gets
SerialMergeScheduler and needs to merge during the second commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2837) listing supported languages
listing supported languages --- Key: SOLR-2837 URL: https://issues.apache.org/jira/browse/SOLR-2837 Project: Solr Issue Type: Improvement Components: contrib - LangId Affects Versions: 3.5, 4.0 Reporter: Koji Sekiguchi Priority: Minor As a user of langid, I'd like to know which languages are supported by current langid, ideally via admin gui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2837) listing supported languages
[
https://issues.apache.org/jira/browse/SOLR-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-2837:
-
Attachment: SOLR-2837.patch
Draft patch that is not ideal version. This is uncool but works for me today.
{code}
$ cd contrib/langid
$ ant -emacs list-supported-lang
list-supported-lang:
da
is
it
no
hu
th
de
el
fi
pt
pl
sv
fr
en
ru
et
es
nl
BUILD SUCCESSFUL
Total time: 0 seconds
{code}
listing supported languages
---
Key: SOLR-2837
URL: https://issues.apache.org/jira/browse/SOLR-2837
Project: Solr
Issue Type: Improvement
Components: contrib - LangId
Affects Versions: 3.5, 4.0
Reporter: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-2837.patch
As a user of langid, I'd like to know which languages are supported by
current langid, ideally via admin gui.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2837) listing supported languages
[
https://issues.apache.org/jira/browse/SOLR-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128312#comment-13128312
]
Robert Muir commented on SOLR-2837:
---
maybe in the main(), change to something like:
{noformat}
System.out.println(lang + : + new Locale(lang).getDisplayLanguage());
{noformat}
on my computer:
{noformat}
da: Danish
is: Icelandic
it: Italian
no: Norwegian
hu: Hungarian
th: Thai
de: German
el: Greek
fi: Finnish
pt: Portuguese
pl: Polish
sv: Swedish
fr: French
en: English
ru: Russian
et: Estonian
es: Spanish
nl: Dutch
{noformat}
on your computer, it might look like:
{noformat}
da: デンマーク語
is: アイスランド語
it: イタリア語
no: ノルウェー語
hu: ハンガリー語
th: タイ語
de: ドイツ語
el: ギリシア語
fi: フィンランド語
pt: ポルトガル語
pl: ポーランド語
sv: スウェーデン語
fr: フランス語
en: 英語
ru: ロシア語
et: エストニア語
es: スペイン語
nl: オランダ語
{noformat}
listing supported languages
---
Key: SOLR-2837
URL: https://issues.apache.org/jira/browse/SOLR-2837
Project: Solr
Issue Type: Improvement
Components: contrib - LangId
Affects Versions: 3.5, 4.0
Reporter: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-2837.patch
As a user of langid, I'd like to know which languages are supported by
current langid, ideally via admin gui.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2837) listing supported languages
[ https://issues.apache.org/jira/browse/SOLR-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128314#comment-13128314 ] Koji Sekiguchi commented on SOLR-2837: -- Cool, thanks! listing supported languages --- Key: SOLR-2837 URL: https://issues.apache.org/jira/browse/SOLR-2837 Project: Solr Issue Type: Improvement Components: contrib - LangId Affects Versions: 3.5, 4.0 Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-2837.patch As a user of langid, I'd like to know which languages are supported by current langid, ideally via admin gui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2838) use preferable default for langid.idField
use preferable default for langid.idField
-
Key: SOLR-2838
URL: https://issues.apache.org/jira/browse/SOLR-2838
Project: Solr
Issue Type: Improvement
Components: contrib - LangId
Affects Versions: 3.5, 4.0
Reporter: Koji Sekiguchi
Priority: Trivial
langid.idField is used for logging purpose in langid. If it is not set, id is
set as default. But if no id field is there and the parameter is likely
hidden and therefore indiscernible for users, those users got undesirable
warnings in the log:
{noformat}
WARNING: Document *null* does not contain input field subject. Skipping this
field.
{noformat}
As we can access IndexSchema in initParams(), why don't we use uniqueKey field
as the default.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2838) use preferable default for langid.idField
[
https://issues.apache.org/jira/browse/SOLR-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-2838:
-
Attachment: SOLR-2838.patch
use preferable default for langid.idField
-
Key: SOLR-2838
URL: https://issues.apache.org/jira/browse/SOLR-2838
Project: Solr
Issue Type: Improvement
Components: contrib - LangId
Affects Versions: 3.5, 4.0
Reporter: Koji Sekiguchi
Priority: Trivial
Attachments: SOLR-2838.patch
langid.idField is used for logging purpose in langid. If it is not set, id
is set as default. But if no id field is there and the parameter is likely
hidden and therefore indiscernible for users, those users got undesirable
warnings in the log:
{noformat}
WARNING: Document *null* does not contain input field subject. Skipping this
field.
{noformat}
As we can access IndexSchema in initParams(), why don't we use uniqueKey
field as the default.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2839) add alternative language detection impl
add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2839: -- Attachment: SOLR-2839.patch patch, needs the language detection jar and its deps from revision 111 of language-detection (in the lib folder), and the profiles files (into the resources folder) add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2839: -- Attachment: (was: SOLR-2839.patch) add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2839: -- Attachment: SOLR-2839.patch add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir Attachments: SOLR-2839.patch based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128324#comment-13128324 ] Robert Muir commented on SOLR-2839: --- this is just for reviewing, there are a lot of svn moves etc (so i doubt you can easily apply it) add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir Attachments: SOLR-2839.patch based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2840) Add max distance as an optional parameter on geodist()
Add max distance as an optional parameter on geodist()
--
Key: SOLR-2840
URL: https://issues.apache.org/jira/browse/SOLR-2840
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Yonik gave the use case. Need the ability to limit results to a max distance.
Name parameter dmax ?
Yes, that should be both possible and faster... something along the lines of:
sfield=storept=45.15,-93.85
facet.query={!geofilt d=10 key=d10}
facet.query={!geofilt d=20 key=d20}
facet.query={!geofilt d=50 key=d50}
Eventually we should implement range faceting over functions and also
add a max distance you care about to the geodist function.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128328#comment-13128328 ] Koji Sekiguchi commented on SOLR-2839: -- bq. based on http://code.google.com/p/language-detection (apache license), supports 53 languages. I've seen that, too. +1. add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir Attachments: SOLR-2839.patch based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3513) Add SimpleFragListBuilder constructor with margin parameter
[
https://issues.apache.org/jira/browse/LUCENE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated LUCENE-3513:
---
Affects Version/s: (was: 3.4)
2.9
Fix Version/s: 4.0
3.5
Assignee: Koji Sekiguchi
Add SimpleFragListBuilder constructor with margin parameter
---
Key: LUCENE-3513
URL: https://issues.apache.org/jira/browse/LUCENE-3513
Project: Lucene - Java
Issue Type: Improvement
Components: modules/highlighter
Affects Versions: 2.9
Reporter: Kelsey Francis
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 3.5, 4.0
Attachments: LUCENE-3513.patch, LUCENE-3513.patch
{{SimpleFragListBuilder}} would benefit from an additional constructor that
takes in {{margin}}. Currently, the margin is defined as a constant, so to
implement a {{FragListBuilder}} with a different margin, one has no choice
but to copy and paste {{SimpleFragListBuilder}} into a new class that must be
placed in the {{org.apache.lucene.search.vectorhighlight}} package due to
accesses of package-protected fields in other classes.
If this change were made, the precondition check of the constructor's
{{fragCharSize}} should probably be altered to ensure that it's less than
{{max(1, margin*3)}} to allow for a margin of 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3513) Add SimpleFragListBuilder constructor with margin parameter
[
https://issues.apache.org/jira/browse/LUCENE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated LUCENE-3513:
---
Attachment: LUCENE-3513.patch
Updated patch attached. I needed to update test. I've also changed the
visibility of the new member variable to package default for the test.
I'll commit soon.
Add SimpleFragListBuilder constructor with margin parameter
---
Key: LUCENE-3513
URL: https://issues.apache.org/jira/browse/LUCENE-3513
Project: Lucene - Java
Issue Type: Improvement
Components: modules/highlighter
Affects Versions: 2.9
Reporter: Kelsey Francis
Priority: Minor
Fix For: 3.5, 4.0
Attachments: LUCENE-3513.patch, LUCENE-3513.patch
{{SimpleFragListBuilder}} would benefit from an additional constructor that
takes in {{margin}}. Currently, the margin is defined as a constant, so to
implement a {{FragListBuilder}} with a different margin, one has no choice
but to copy and paste {{SimpleFragListBuilder}} into a new class that must be
placed in the {{org.apache.lucene.search.vectorhighlight}} package due to
accesses of package-protected fields in other classes.
If this change were made, the precondition check of the constructor's
{{fragCharSize}} should probably be altered to ensure that it's less than
{{max(1, margin*3)}} to allow for a margin of 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128335#comment-13128335 ] Robert Muir commented on SOLR-2839: --- ok, i'd like to add this basic implementation first. later, we should add support for some advanced parameters and refactoring: * whitelisting should not happen in the base class as a post-filter (though this is fine as a default implementation), but subclasses should override i think. For this detector, it could improve performance. * for this detector whitelist should support priors too (e.g. en=0.5, fr=0.1). * we should add support for configuring smoothing parameter and maxTextLength (and, the base class's concat should respect that too). * both this implementation and the tika implementation are copying objects across lists of language information, i think this is not very efficient to do per-document. So I think we should change the API from ListDetectedLanguage detectLanguage() to IterableDetectedLanguage detectLanguage. It seems in general it just wants the first one anyway. add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir Attachments: SOLR-2839.patch based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reassigned SOLR-2839: - Assignee: Robert Muir add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir Assignee: Robert Muir Fix For: 3.5, 4.0 Attachments: SOLR-2839.patch based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2839: -- Fix Version/s: 4.0 3.5 add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir Assignee: Robert Muir Fix For: 3.5, 4.0 Attachments: SOLR-2839.patch based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3513) Add SimpleFragListBuilder constructor with margin parameter
[
https://issues.apache.org/jira/browse/LUCENE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi resolved LUCENE-3513.
Resolution: Fixed
committed in trunk and 3x. Thanks, Kelsey!
Add SimpleFragListBuilder constructor with margin parameter
---
Key: LUCENE-3513
URL: https://issues.apache.org/jira/browse/LUCENE-3513
Project: Lucene - Java
Issue Type: Improvement
Components: modules/highlighter
Affects Versions: 2.9
Reporter: Kelsey Francis
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 3.5, 4.0
Attachments: LUCENE-3513.patch, LUCENE-3513.patch
{{SimpleFragListBuilder}} would benefit from an additional constructor that
takes in {{margin}}. Currently, the margin is defined as a constant, so to
implement a {{FragListBuilder}} with a different margin, one has no choice
but to copy and paste {{SimpleFragListBuilder}} into a new class that must be
placed in the {{org.apache.lucene.search.vectorhighlight}} package due to
accesses of package-protected fields in other classes.
If this change were made, the precondition check of the constructor's
{{fragCharSize}} should probably be altered to ensure that it's less than
{{max(1, margin*3)}} to allow for a margin of 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2839) add alternative language detection impl
[ https://issues.apache.org/jira/browse/SOLR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-2839. --- Resolution: Fixed add alternative language detection impl --- Key: SOLR-2839 URL: https://issues.apache.org/jira/browse/SOLR-2839 Project: Solr Issue Type: Improvement Reporter: Robert Muir Assignee: Robert Muir Fix For: 3.5, 4.0 Attachments: SOLR-2839.patch based on http://code.google.com/p/language-detection (apache license), supports 53 languages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
