[jira] [Resolved] (SOLR-3228) Backport CurrencyField to 3.x
[ https://issues.apache.org/jira/browse/SOLR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-3228. --- Resolution: Fixed Committed this as part of SOLR-2202 instead Backport CurrencyField to 3.x - Key: SOLR-3228 URL: https://issues.apache.org/jira/browse/SOLR-3228 Project: Solr Issue Type: New Feature Components: Schema and Analysis Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 3.6 Attachments: SOLR-3228.patch Backport SOLR-2202 to branch_3x -- 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-2202) Money/Currency FieldType
[ https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-2202: -- Fix Version/s: 3.6 Backport from SOLR-3228 committed to branch_3x Money/Currency FieldType Key: SOLR-2202 URL: https://issues.apache.org/jira/browse/SOLR-2202 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 1.5 Reporter: Greg Fodor Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch Provides support for monetary values to Solr/Lucene with query-time currency conversion. The following features are supported: - Point queries - Range quries - Sorting - Currency parsing by either currency code or symbol. - Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are useful if there are fees associated with exchanging the currency.) At indexing time, money fields can be indexed in a native currency. For example, if a product on an e-commerce site is listed in Euros, indexing the price field as 1000,EUR will index it appropriately. By altering the currency.xml file, the sorting and querying against Solr can take into account fluctuations in currency exchange rates without having to re-index the documents. The new money field type is a polyfield which indexes two fields, one which contains the amount of the value and another which contains the currency code or symbol. The currency metadata (names, symbols, codes, and exchange rates) are expected to be in an xml file which is pointed to by the field type declaration in the schema.xml. The current patch is factored such that Money utility functions and configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), while the MoneyType and MoneyValueSource lie in Solr. This was meant to mirror the work being done on the spacial field types. This patch will be getting used to power the international search capabilities of the search engine at Etsy. Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType -- 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
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1928 - Failure
This was caused by a timeout? [junit] Caused by: org.apache.commons.httpclient.ConnectTimeoutException: The host did not accept the connection within timeout of 100 ms I don't think this is reasonable on jenkins? Dawid On Sat, Mar 10, 2012 at 1:02 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1928/ 1 tests failed. REGRESSION: org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest.testMultiThreaded Error Message: Uncaught exception by thread: Thread[DocThread-2,5,] Stack Trace: org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread: Uncaught exception by thread: Thread[DocThread-2,5,] at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:60) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.client.solrj.LargeVolumeTestBase$DocThread.run(LargeVolumeTestBase.java:120) Build Log (for compile errors): [...truncated 9510 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3026) eDismax: Locking down which fields can be explicitly queried (user fields aka uf)
[ https://issues.apache.org/jira/browse/SOLR-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3026: -- Attachment: SOLR-3026.patch Just some minor polishings. Will commit this to trunk now. eDismax: Locking down which fields can be explicitly queried (user fields aka uf) - Key: SOLR-3026 URL: https://issues.apache.org/jira/browse/SOLR-3026 Project: Solr Issue Type: Improvement Components: search Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5 Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch We need a way to specify exactly what fields should be available to the end user as fielded search. In the original SOLR-1553, there's a patch implementing user fields, but it was never committed even if that issue was closed. -- 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] Solr-trunk - Build # 1789 - Failure
Build: https://builds.apache.org/job/Solr-trunk/1789/ 3 tests failed. REGRESSION: org.apache.solr.TestDistributedSearch.testDistribSearch Error Message: Uncaught exception by thread: Thread[Thread-662,5,] Stack Trace: org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread: Uncaught exception by thread: Thread[Thread-662,5,] at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:60) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) Caused by: java.lang.RuntimeException: org.apache.solr.client.solrj.SolrServerException: http://localhost:23892/solr at org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:374) Caused by: org.apache.solr.client.solrj.SolrServerException: http://localhost:23892/solr at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:496) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:251) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:312) at org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:369) Caused by: org.apache.commons.httpclient.ConnectTimeoutException: The host did not accept the connection within timeout of 100 ms at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:155) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:426) Caused by: java.net.SocketTimeoutException: connect timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=92 closes=91 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=92 closes=91 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) REGRESSION: org.apache.solr.cloud.OverseerTest.testShardLeaderChange Error Message: Unexpected shard leader coll:collection1 shard:shard1 expected:core4 but was:null Stack Trace: junit.framework.AssertionFailedError: Unexpected shard leader coll:collection1 shard:shard1 expected:core4 but was:null at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at
[jira] [Commented] (SOLR-3026) eDismax: Locking down which fields can be explicitly queried (user fields aka uf)
[ https://issues.apache.org/jira/browse/SOLR-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226806#comment-13226806 ] Jan Høydahl commented on SOLR-3026: --- Committed to trunk. Starting to backport eDismax: Locking down which fields can be explicitly queried (user fields aka uf) - Key: SOLR-3026 URL: https://issues.apache.org/jira/browse/SOLR-3026 Project: Solr Issue Type: Improvement Components: search Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5 Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch We need a way to specify exactly what fields should be available to the end user as fielded search. In the original SOLR-1553, there's a patch implementing user fields, but it was never committed even if that issue was closed. -- 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-2202) Money/Currency FieldType
[ https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226807#comment-13226807 ] Jan Høydahl commented on SOLR-2202: --- Updated Wiki: http://wiki.apache.org/solr/CurrencyField Money/Currency FieldType Key: SOLR-2202 URL: https://issues.apache.org/jira/browse/SOLR-2202 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 1.5 Reporter: Greg Fodor Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch Provides support for monetary values to Solr/Lucene with query-time currency conversion. The following features are supported: - Point queries - Range quries - Sorting - Currency parsing by either currency code or symbol. - Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are useful if there are fees associated with exchanging the currency.) At indexing time, money fields can be indexed in a native currency. For example, if a product on an e-commerce site is listed in Euros, indexing the price field as 1000,EUR will index it appropriately. By altering the currency.xml file, the sorting and querying against Solr can take into account fluctuations in currency exchange rates without having to re-index the documents. The new money field type is a polyfield which indexes two fields, one which contains the amount of the value and another which contains the currency code or symbol. The currency metadata (names, symbols, codes, and exchange rates) are expected to be in an xml file which is pointed to by the field type declaration in the schema.xml. The current patch is factored such that Money utility functions and configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), while the MoneyType and MoneyValueSource lie in Solr. This was meant to mirror the work being done on the spacial field types. This patch will be getting used to power the international search capabilities of the search engine at Etsy. Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType -- 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-3230) FastGeo Filter Feature
FastGeo Filter Feature
--
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Fix For: 4.0
This adds a {!fastgeo} that works with LatLong types.
It does a boundary box, and then does an exact haversine result.
{code}
@Override
public Query rewrite(IndexReader reader) throws IOException {
System.out.println(In rewrite bboxQuery + (bboxQuery == null ? null :
not null));
System.out.println(In rewrite fastgeo + (fastgeo ? true : false));
if (fastgeo) {
Query query = bboxQuery.rewrite(reader);
IndexSearcher searcher = new IndexSearcher(reader);
SpatialWeight w = new SpatialWeight(searcher);
return query;
} else
return bboxQuery != null ? bboxQuery.rewrite(reader) : this;
}
{code}
--
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-3076) Solr should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-3076: --- Attachment: tochild-bjq-filtered-search-fix.patch tochild-bjq-filtered-search-fix.patch covers filtered search by ToChildBJQ and has two fixes for it. Lucene codebase is impacted only. Michael, Please consider it for commit. Thanks Solr should support block joins --- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Attachments: SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, parent-bjq-qparser.patch, parent-bjq-qparser.patch, solrconf-bjq-erschema-snippet.xml, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- 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-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226849#comment-13226849 ] Andrew Morrison commented on SOLR-3218: --- That was fast. I'll submit an updated patch soon. Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226868#comment-13226868
]
Christian Moen commented on LUCENE-3767:
Thanks for the feedback.
Mike, you are right that the added files aren't included in the patch, but I
believe they will be added on check-in. (I've verified that they're marked for
addition, including {{RollingCharBuffer}}. Sorry for the confusion.)
I believe the patch is correct with regards to {{svn:mergeinfo}} -- only the
root directory, {{lucene}} and {{solr}} should have them.
I'll commit to {{branch_3x}} shortly.
Explore streaming Viterbi search in Kuromoji
Key: LUCENE-3767
URL: https://issues.apache.org/jira/browse/LUCENE-3767
Project: Lucene - Java
Issue Type: Improvement
Components: modules/analysis
Reporter: Michael McCandless
Assignee: Christian Moen
Fix For: 3.6, 4.0
Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767_branch_3x.patch,
SolrXml-5498.xml, compound_diffs.txt
I've been playing with the idea of changing the Kuromoji viterbi
search to be 2 passes (intersect, backtrace) instead of 4 passes
(break into sentences, intersect, score, backtrace)... this is very
much a work in progress, so I'm just getting my current state up.
It's got tons of nocommits, doesn't properly handle the user dict nor
extended modes yet, etc.
One thing I'm playing with is to add a double backtrace for the long
compound tokens, ie, instead of penalizing these tokens so that
shorter tokens are picked, leave the scores unchanged but on backtrace
take that penalty and use it as a threshold for a 2nd best
segmentation...
--
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-3859) nuke/clean up AtomicReader.hasNorms
[ https://issues.apache.org/jira/browse/LUCENE-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3859: Attachment: LUCENE-3859.patch Updated patch: same approach as before, except with some related cleanups. FieldInfos are now public from IndexReader in 4.0, but javadoc is sparse and some naming is inconsistent. Patch renames FieldInfos.anyDocValuesFields() to FieldInfos.hasDocValues(), consistent with hasProx(), hasNorms(), and hasFreq(). Patch also renames FieldInfo.normsPresent() to FieldInfo.hasNorms(), consistent with hasDocValues(), and consistent with the naming in FieldInfoS. Also i added some additional javadoc. nuke/clean up AtomicReader.hasNorms --- Key: LUCENE-3859 URL: https://issues.apache.org/jira/browse/LUCENE-3859 Project: Lucene - Java Issue Type: Task Affects Versions: 4.0 Reporter: Robert Muir Attachments: LUCENE-3859.patch, LUCENE-3859.patch implementations already have to return fieldInfos() [which can tell you this], and normValues() [which can also tell you this]. So if we want to keep it, I think it should just have a final implementation and not be required for FilterReaders, etc. Or we can just nuke it... do we really need 3 ways to do the same thing? -- 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-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226872#comment-13226872
]
Christian Moen commented on LUCENE-3767:
Committed revision 1299213 on {{branch_3x}}
Explore streaming Viterbi search in Kuromoji
Key: LUCENE-3767
URL: https://issues.apache.org/jira/browse/LUCENE-3767
Project: Lucene - Java
Issue Type: Improvement
Components: modules/analysis
Reporter: Michael McCandless
Assignee: Christian Moen
Fix For: 3.6, 4.0
Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767_branch_3x.patch,
SolrXml-5498.xml, compound_diffs.txt
I've been playing with the idea of changing the Kuromoji viterbi
search to be 2 passes (intersect, backtrace) instead of 4 passes
(break into sentences, intersect, score, backtrace)... this is very
much a work in progress, so I'm just getting my current state up.
It's got tons of nocommits, doesn't properly handle the user dict nor
extended modes yet, etc.
One thing I'm playing with is to add a double backtrace for the long
compound tokens, ie, instead of penalizing these tokens so that
shorter tokens are picked, leave the scores unchanged but on backtrace
take that penalty and use it as a threshold for a 2nd best
segmentation...
--
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-3821) SloppyPhraseScorer sometimes misses documents that ExactPhraseScorer finds.
[
https://issues.apache.org/jira/browse/LUCENE-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226873#comment-13226873
]
Robert Muir commented on LUCENE-3821:
-
{quote}
Robert, this gave me an idea... currently, in case of collision between
repeaters, we compare them and advance the lesser of them
(SloppyPhraseScorer.lesser(PhrasePositions, PhrasePositions)) - it should be
fairly easy to add lookahead to this logic: if one of the two is multi-term,
lesser can also do a lookahead. The amount of lookahead can depend on the slop.
I'll give it a try before closing this issue.
{quote}
Interesting... its hard to think about for me since the edit distance is a
little different, but at least in the
levAutomata case the maximum 'context' the thing ever needs is {{2n+1}}, where
n is the distance/slop. I don't
know if it applies here... but seems like it should be at least an upperbound.
Speaking of which on a related note, I think its possible we can implement a
more... exhaustive test for
SloppyPhraseScorer (rather than relying so much on a random one). The idea
would be a twist on
TestLevenshteinAutomata.assertCharVectors: using an alphabet of terms={0,1} the
idea is to test all possible
'automaton structures', for sloppyphrasescorer, the idea would be we have the
minimal test method that
tests all the cases...
I'll think on this one...
SloppyPhraseScorer sometimes misses documents that ExactPhraseScorer finds.
---
Key: LUCENE-3821
URL: https://issues.apache.org/jira/browse/LUCENE-3821
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 3.5, 4.0
Reporter: Naomi Dushay
Assignee: Doron Cohen
Attachments: LUCENE-3821-SloppyDecays.patch, LUCENE-3821.patch,
LUCENE-3821.patch, LUCENE-3821.patch, LUCENE-3821.patch,
LUCENE-3821_test.patch, schema.xml, solrconfig-test.xml
The general bug is a case where a phrase with no slop is found,
but if you add slop its not.
I committed a test today (TestSloppyPhraseQuery2) that actually triggers this
case,
jenkins just hasn't had enough time to chew on it.
ant test -Dtestcase=TestSloppyPhraseQuery2 -Dtests.iter=100 is enough to make
it fail on trunk or 3.x
--
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-3223) excludes the lower bound in inclusive range queries with characters
[ https://issues.apache.org/jira/browse/SOLR-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226876#comment-13226876 ] Steven Rowe commented on SOLR-3223: --- abhimanyu, this does not appear to be a bug, but rather a question of how to use Solr. Please ask your question again on the solr users' mailing list: [http://lucene.apache.org/solr/discussion.html]. excludes the lower bound in inclusive range queries with characters Key: SOLR-3223 URL: https://issues.apache.org/jira/browse/SOLR-3223 Project: Solr Issue Type: Bug Affects Versions: 3.5, 4.0 Reporter: abhimanyu Labels: range, text while using a range query to retrieve all the record over a inclusive range with characters , eg name : [a TO e] the returned result set excludes the lower bound in range query, like in this case it does not include the results with 'e' . Please suggest any solution for this . -- 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] [Closed] (SOLR-3223) excludes the lower bound in inclusive range queries with characters
[ https://issues.apache.org/jira/browse/SOLR-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe closed SOLR-3223. - excludes the lower bound in inclusive range queries with characters Key: SOLR-3223 URL: https://issues.apache.org/jira/browse/SOLR-3223 Project: Solr Issue Type: Bug Affects Versions: 3.5, 4.0 Reporter: abhimanyu Labels: range, text while using a range query to retrieve all the record over a inclusive range with characters , eg name : [a TO e] the returned result set excludes the lower bound in range query, like in this case it does not include the results with 'e' . Please suggest any solution for this . -- 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-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226881#comment-13226881
]
Christian Moen commented on LUCENE-3767:
Confirmed this working in a {{branch_3x}} build.
Thanks, Mike and Robert! :)
Explore streaming Viterbi search in Kuromoji
Key: LUCENE-3767
URL: https://issues.apache.org/jira/browse/LUCENE-3767
Project: Lucene - Java
Issue Type: Improvement
Components: modules/analysis
Reporter: Michael McCandless
Assignee: Christian Moen
Fix For: 3.6, 4.0
Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767_branch_3x.patch,
SolrXml-5498.xml, compound_diffs.txt
I've been playing with the idea of changing the Kuromoji viterbi
search to be 2 passes (intersect, backtrace) instead of 4 passes
(break into sentences, intersect, score, backtrace)... this is very
much a work in progress, so I'm just getting my current state up.
It's got tons of nocommits, doesn't properly handle the user dict nor
extended modes yet, etc.
One thing I'm playing with is to add a double backtrace for the long
compound tokens, ie, instead of penalizing these tokens so that
shorter tokens are picked, leave the scores unchanged but on backtrace
take that penalty and use it as a threshold for a 2nd best
segmentation...
--
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-3767) Explore streaming Viterbi search in Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Moen resolved LUCENE-3767. Resolution: Fixed Explore streaming Viterbi search in Kuromoji Key: LUCENE-3767 URL: https://issues.apache.org/jira/browse/LUCENE-3767 Project: Lucene - Java Issue Type: Improvement Components: modules/analysis Reporter: Michael McCandless Assignee: Christian Moen Fix For: 3.6, 4.0 Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767_branch_3x.patch, SolrXml-5498.xml, compound_diffs.txt I've been playing with the idea of changing the Kuromoji viterbi search to be 2 passes (intersect, backtrace) instead of 4 passes (break into sentences, intersect, score, backtrace)... this is very much a work in progress, so I'm just getting my current state up. It's got tons of nocommits, doesn't properly handle the user dict nor extended modes yet, etc. One thing I'm playing with is to add a double backtrace for the long compound tokens, ie, instead of penalizing these tokens so that shorter tokens are picked, leave the scores unchanged but on backtrace take that penalty and use it as a threshold for a 2nd best segmentation... -- 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
regarding GSOC 2012
Hi, I was wondering if Apache lucene is participating in GSOC this year as I found this page https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=labels+%3D+lucene-gsoc-12 about project ideas but it has no JIRAs except for the gsoc participation announcement. I would like to discuss the possibility for a gsoc project. I am fairly proficient with Java and am currently in my final year in IIT Delhi, India. I have worked with lucene in the past too. Regards, Abhishek Sagar 5th year Dual Degree Student(Btech+Mtech) CSE, IIT Delhi India - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: regarding GSOC 2012
Hey, yeah we are going to participate. I just flagged a bunch of lucene-gsoc-11 issues as lucene-gsoc-12 but you can go ahead and scan through jira and find one yourself. What parts are you interested? simon On Sat, Mar 10, 2012 at 4:05 PM, Abhishek Sagar cs5070...@cse.iitd.ac.in wrote: Hi, I was wondering if Apache lucene is participating in GSOC this year as I found this page https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=labels+%3D+lucene-gsoc-12 this link should give you some results now simon about project ideas but it has no JIRAs except for the gsoc participation announcement. I would like to discuss the possibility for a gsoc project. I am fairly proficient with Java and am currently in my final year in IIT Delhi, India. I have worked with lucene in the past too. Regards, Abhishek Sagar 5th year Dual Degree Student(Btech+Mtech) CSE, IIT Delhi India - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Applying for GSoC 2012 under Apache Lucene project
we have a wiki to get started! check this out http://wiki.apache.org/lucene-java/SummerOfCode2012 simon On Tue, Feb 7, 2012 at 6:57 AM, Shakya Wijerama shakya.wijer...@gmail.com wrote: Hi all, I am a novice to Apache Lucene project and would like learn and understand the core of the project. Also I want to apply Google Summer of Codes 2012 if I get any chance to. Can you tell me how should I start working with the project to move forward? Thanks. -- Regards, Shakya Wijerama Senior Student, Faculty of Applied Sciences, Sabaragamuwa University of Sri Lanka. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: GSOC 2012?
Mark, can you open an issue for this and lable it as: gsoc2012 lucene-gsoc-12 mentor just like this one https://issues.apache.org/jira/browse/LUCENE-2562 thanks, simon On Fri, Mar 2, 2012 at 12:26 PM, mark harwood markharw...@yahoo.co.uk wrote: Does anyone have any ideas? A framework for match metadata? Similar to the way tokenization was changed to allow tokenizers to to enrich a stream of tokens with arbitrary attributes, Scorers could provide MatchAttributes to provide arbitrary metadata about the stream of matches they produce. Same model is used - callers decide in advance which attribute decorations they want to consume and Scorers modify a singleton object which can be cloned if multiple attributes need to be retained by the caller. Helps support highlighting, explain and enables communication of added information between query objects in the tree. LUCENE-1999 was an example of a horrible work-around where additional match information that was required was smuggled through by bit-twiddling the score - this is because score is the only bit of match context we currently pass in Lucene APIs. Cheers Mark From: Robert Muir rcm...@gmail.com To: dev@lucene.apache.org Sent: Friday, 2 March 2012, 10:30 Subject: GSOC 2012? Hello, I was asked by a student if we are participating in GSOC this year. I hope the answer is yes? If we are planning to, I think it would be good if we came up with a list on the wiki of potential tasks. Does anyone have any ideas? One suggested idea I had (similar to LUCENE-2959 last year) would be to add a flexible query expansion framework. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1936 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1936/ 1 tests failed. REGRESSION: org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds Error Message: searcher529 wasn't soon enough after soft529: 1331409277447 ! 1331409277134 + 200 (fudge) Stack Trace: junit.framework.AssertionFailedError: searcher529 wasn't soon enough after soft529: 1331409277447 ! 1331409277134 + 200 (fudge) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds(SoftAutoCommitTest.java:122) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) Build Log (for compile errors): [...truncated 8486 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3011) DIH MultiThreaded bug
[ https://issues.apache.org/jira/browse/SOLR-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226934#comment-13226934 ] Mikhail Khludnev commented on SOLR-3011: Ok. I've got what the problem is. But it's much more complicate than I could imagine. MockDataSource which is used for cover all DIH stores an iterators, not a collections as a resultsets. So, you retrieve such result set as an iterator, exhaust it, than you can retrieve the same exhausted resultset again and get that it's empty. That's not a case for the real SQL datasource, it works as a collection: every time you get the brand new resultset. After I amend MockDataSource to provide collections, most of tests fail. As far as I understand your particular fix doesn't work for parent-child case. I'm on the long road for providing a fix. Thanks for spotting it. It's absolutely useful. DIH MultiThreaded bug - Key: SOLR-3011 URL: https://issues.apache.org/jira/browse/SOLR-3011 Project: Solr Issue Type: Sub-task Components: contrib - DataImportHandler Affects Versions: 3.5, 4.0 Reporter: Mikhail Khludnev Priority: Minor Fix For: 4.0 Attachments: SOLR-3011.patch, SOLR-3011.patch, patch-3011-EntityProcessorBase-iterator.patch current DIH design is not thread safe. see last comments at SOLR-2382 and SOLR-2947. I'm going to provide the patch makes DIH core threadsafe. Mostly it's a SOLR-2947 patch from 28th Dec. -- 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-3011) DIH MultiThreaded bug
[ https://issues.apache.org/jira/browse/SOLR-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wenca Petr updated SOLR-3011: - Attachment: patch-3011-EntityProcessorBase-iterator.patch You are right. I found it also trying to index my data with parent-child entities. I think that the best way would be to provide some flag that the entity is/is not done and the flag would be tested when a particular row iterator reaches the end. I made another quick and dirty fix ;-). I set the iterator to null in getNext() just for non root entities. For root entity the iterator is left as in my previous patch. DIH MultiThreaded bug - Key: SOLR-3011 URL: https://issues.apache.org/jira/browse/SOLR-3011 Project: Solr Issue Type: Sub-task Components: contrib - DataImportHandler Affects Versions: 3.5, 4.0 Reporter: Mikhail Khludnev Priority: Minor Fix For: 4.0 Attachments: SOLR-3011.patch, SOLR-3011.patch, patch-3011-EntityProcessorBase-iterator.patch, patch-3011-EntityProcessorBase-iterator.patch current DIH design is not thread safe. see last comments at SOLR-2382 and SOLR-2947. I'm going to provide the patch makes DIH core threadsafe. Mostly it's a SOLR-2947 patch from 28th Dec. -- 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] (LUCENE-3581) IndexReader#isCurrent() should return true on a NRT reader if no deletes are applied and only deletes are present in IW
[ https://issues.apache.org/jira/browse/LUCENE-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer reassigned LUCENE-3581: --- Assignee: Simon Willnauer IndexReader#isCurrent() should return true on a NRT reader if no deletes are applied and only deletes are present in IW --- Key: LUCENE-3581 URL: https://issues.apache.org/jira/browse/LUCENE-3581 Project: Lucene - Java Issue Type: Bug Affects Versions: 3.5, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 3.6, 4.0 I keep forgetting about this, I better open an issue. If you have a NRT reader without deletes applied it should infact return true on IR#isCurrent() if the IW only has deletes in its buffer ie. no documents where updated / added since the NRT reader was opened. Currently if there is a delete coming in we force a reopen which does nothing since deletes are not applied anyway. -- 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-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226978#comment-13226978 ] Ryan McKinley commented on SOLR-3159: - They had a real 8.1.2 release... and I upgraded the .jar files in revision: 1299325 Upgrade to Jetty 8 -- Key: SOLR-3159 URL: https://issues.apache.org/jira/browse/SOLR-3159 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Attachments: SOLR-3159-maven.patch Solr is currently tested (and bundled) with a patched jetty-6 version. Ideally we can release and test with a standard version. Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8. -- 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-3231) Add the ability to KStemmer to preserve the original token when stemming
[ https://issues.apache.org/jira/browse/SOLR-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie Johnson updated SOLR-3231: Attachment: KStemFilter.patch Add the ability to KStemmer to preserve the original token when stemming Key: SOLR-3231 URL: https://issues.apache.org/jira/browse/SOLR-3231 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Jamie Johnson Attachments: KStemFilter.patch While using the PorterStemmer, I found that there were often times that it was far to aggressive in it's stemming. In my particular case it is unrealistic to provide a protected word list which captures all possible words which should not be stemmed. To avoid this I proposed a solution whereby we store the original token as well as the stemmed token so exact searches would always work. Based on discussions on the mailing list Ahmet Arslan, I believe the attached patch to KStemmer provides the desired capabilities through a configuration parameter. This largely is a copy of the org.apache.lucene.wordnet.SynonymTokenFilter. -- 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-3231) Add the ability to KStemmer to preserve the original token when stemming
Add the ability to KStemmer to preserve the original token when stemming Key: SOLR-3231 URL: https://issues.apache.org/jira/browse/SOLR-3231 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Jamie Johnson Attachments: KStemFilter.patch While using the PorterStemmer, I found that there were often times that it was far to aggressive in it's stemming. In my particular case it is unrealistic to provide a protected word list which captures all possible words which should not be stemmed. To avoid this I proposed a solution whereby we store the original token as well as the stemmed token so exact searches would always work. Based on discussions on the mailing list Ahmet Arslan, I believe the attached patch to KStemmer provides the desired capabilities through a configuration parameter. This largely is a copy of the org.apache.lucene.wordnet.SynonymTokenFilter. -- 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-3231) Add the ability to KStemmer to preserve the original token when stemming
[ https://issues.apache.org/jira/browse/SOLR-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie Johnson updated SOLR-3231: Attachment: (was: KStemFilter.patch) Add the ability to KStemmer to preserve the original token when stemming Key: SOLR-3231 URL: https://issues.apache.org/jira/browse/SOLR-3231 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Jamie Johnson Attachments: KStemFilter.patch While using the PorterStemmer, I found that there were often times that it was far to aggressive in it's stemming. In my particular case it is unrealistic to provide a protected word list which captures all possible words which should not be stemmed. To avoid this I proposed a solution whereby we store the original token as well as the stemmed token so exact searches would always work. Based on discussions on the mailing list Ahmet Arslan, I believe the attached patch to KStemmer provides the desired capabilities through a configuration parameter. This largely is a copy of the org.apache.lucene.wordnet.SynonymTokenFilter. -- 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-3231) Add the ability to KStemmer to preserve the original token when stemming
[ https://issues.apache.org/jira/browse/SOLR-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie Johnson updated SOLR-3231: Attachment: KStemFilter.patch Add the ability to KStemmer to preserve the original token when stemming Key: SOLR-3231 URL: https://issues.apache.org/jira/browse/SOLR-3231 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Jamie Johnson Attachments: KStemFilter.patch While using the PorterStemmer, I found that there were often times that it was far to aggressive in it's stemming. In my particular case it is unrealistic to provide a protected word list which captures all possible words which should not be stemmed. To avoid this I proposed a solution whereby we store the original token as well as the stemmed token so exact searches would always work. Based on discussions on the mailing list Ahmet Arslan, I believe the attached patch to KStemmer provides the desired capabilities through a configuration parameter. This largely is a copy of the org.apache.lucene.wordnet.SynonymTokenFilter. -- 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-trunk - Build # 1857 - Failure
Build: https://builds.apache.org/job/Lucene-trunk/1857/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestMixedCodecs.test Error Message: background merge hit exception: _94(4.0):cv397 _93(4.0):cv8316 into _95 [maxNumSegments=1] Stack Trace: java.io.IOException: background merge hit exception: _94(4.0):cv397 _93(4.0):cv8316 into _95 [maxNumSegments=1] at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1732) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1669) at org.apache.lucene.index.RandomIndexWriter.doRandomForceMerge(RandomIndexWriter.java:357) at org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:406) at org.apache.lucene.index.TestMixedCodecs.test(TestMixedCodecs.java:57) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) Caused by: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.store.RAMFile.newBuffer(RAMFile.java:73) at org.apache.lucene.store.RAMFile.addBuffer(RAMFile.java:46) at org.apache.lucene.store.RAMOutputStream.switchCurrentBuffer(RAMOutputStream.java:152) at org.apache.lucene.store.RAMOutputStream.writeBytes(RAMOutputStream.java:138) at org.apache.lucene.store.MockIndexOutputWrapper.writeBytes(MockIndexOutputWrapper.java:119) at org.apache.lucene.util.ThrottledIndexOutput.writeBytes(ThrottledIndexOutput.java:108) at org.apache.lucene.util.ThrottledIndexOutput.writeByte(ThrottledIndexOutput.java:102) at org.apache.lucene.store.DataOutput.writeInt(DataOutput.java:58) at org.apache.lucene.store.CompoundFileWriter.writeEntryTable(CompoundFileWriter.java:233) at org.apache.lucene.store.CompoundFileWriter.close(CompoundFileWriter.java:177) at org.apache.lucene.store.CompoundFileDirectory.close(CompoundFileDirectory.java:206) at org.apache.lucene.index.IndexWriter.createCompoundFile(IndexWriter.java:4083) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3650) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257) at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451) Build Log (for compile errors): [...truncated 13476 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-2202) Money/Currency FieldType
[
https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi reopened SOLR-2202:
--
Reopening, as CurrencyField depends on the definition tlong in schema.xml and
I don't think it is a good idea.
If tlong fieldType is not there, I got NPE.
{code:title=CurrencyField.java}
protected static final String FIELD_TYPE_CURRENCY = string;
protected static final String FIELD_TYPE_AMOUNT_RAW = tlong;
{code}
Money/Currency FieldType
Key: SOLR-2202
URL: https://issues.apache.org/jira/browse/SOLR-2202
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Affects Versions: 1.5
Reporter: Greg Fodor
Assignee: Jan Høydahl
Fix For: 3.6, 4.0
Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch,
SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch,
SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch,
SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch,
SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch,
SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch
Provides support for monetary values to Solr/Lucene with query-time currency
conversion. The following features are supported:
- Point queries
- Range quries
- Sorting
- Currency parsing by either currency code or symbol.
- Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are
useful if there are fees associated with exchanging the currency.)
At indexing time, money fields can be indexed in a native currency. For
example, if a product on an e-commerce site is listed in Euros, indexing the
price field as 1000,EUR will index it appropriately. By altering the
currency.xml file, the sorting and querying against Solr can take into
account fluctuations in currency exchange rates without having to re-index
the documents.
The new money field type is a polyfield which indexes two fields, one which
contains the amount of the value and another which contains the currency code
or symbol. The currency metadata (names, symbols, codes, and exchange rates)
are expected to be in an xml file which is pointed to by the field type
declaration in the schema.xml.
The current patch is factored such that Money utility functions and
configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig),
while the MoneyType and MoneyValueSource lie in Solr. This was meant to
mirror the work being done on the spacial field types.
This patch will be getting used to power the international search
capabilities of the search engine at Etsy.
Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType
--
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-2202) Money/Currency FieldType
[ https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2202: - Attachment: SOLR-2202-fix-NPE-if-no-tlong-fieldType.patch A draft patch which hasn't been tested yet. Money/Currency FieldType Key: SOLR-2202 URL: https://issues.apache.org/jira/browse/SOLR-2202 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 1.5 Reporter: Greg Fodor Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-fix-NPE-if-no-tlong-fieldType.patch, SOLR-2202-lucene-1.patch, SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch Provides support for monetary values to Solr/Lucene with query-time currency conversion. The following features are supported: - Point queries - Range quries - Sorting - Currency parsing by either currency code or symbol. - Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are useful if there are fees associated with exchanging the currency.) At indexing time, money fields can be indexed in a native currency. For example, if a product on an e-commerce site is listed in Euros, indexing the price field as 1000,EUR will index it appropriately. By altering the currency.xml file, the sorting and querying against Solr can take into account fluctuations in currency exchange rates without having to re-index the documents. The new money field type is a polyfield which indexes two fields, one which contains the amount of the value and another which contains the currency code or symbol. The currency metadata (names, symbols, codes, and exchange rates) are expected to be in an xml file which is pointed to by the field type declaration in the schema.xml. The current patch is factored such that Money utility functions and configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), while the MoneyType and MoneyValueSource lie in Solr. This was meant to mirror the work being done on the spacial field types. This patch will be getting used to power the international search capabilities of the search engine at Etsy. Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType -- 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-3232) Admin UI: query form should have a menu to pick a request handler
Admin UI: query form should have a menu to pick a request handler - Key: SOLR-3232 URL: https://issues.apache.org/jira/browse/SOLR-3232 Project: Solr Issue Type: Improvement Components: web gui Reporter: David Smiley Fix For: 4.0 The query form in the admin UI could use an improvement regarding how the request handler is chosen; presently all there is is a text input for 'qt'. The first choice to make in the form above the query should really be the request handler since it actually handles the request before any other parameters do anything. It'd be great if it was a dynamically driven menu defaulting to /select. Similar to how the DIH page finds DIH request handlers, this page could find the request handlers with a class of SearchHandler. Their names would be added to a list, and if the name didn't start with a '/' then it would be prefixed with '/select?qt='. I did something similar (without the menu) to the old 3x UI in a patch to SOLR-3161 which will hopefully get committed. -- 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-3230) FastGeo Filter Feature
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227001#comment-13227001
]
David Smiley commented on SOLR-3230:
Hi Bill. It appears you forgot to supply a patch.
FastGeo Filter Feature
--
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Fix For: 4.0
This adds a {!fastgeo} that works with LatLong types.
It does a boundary box, and then does an exact haversine result.
{code}
@Override
public Query rewrite(IndexReader reader) throws IOException {
System.out.println(In rewrite bboxQuery + (bboxQuery == null ? null
: not null));
System.out.println(In rewrite fastgeo + (fastgeo ? true : false));
if (fastgeo) {
Query query = bboxQuery.rewrite(reader);
IndexSearcher searcher = new IndexSearcher(reader);
SpatialWeight w = new SpatialWeight(searcher);
return query;
} else
return bboxQuery != null ? bboxQuery.rewrite(reader) : this;
}
{code}
--
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] Solr-3.x - Build # 626 - Failure
Build: https://builds.apache.org/job/Solr-3.x/626/ No tests ran. Build Log (for compile errors): [...truncated 30096 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-3230:
Description:
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
was:
This adds a {!fastgeo} that works with LatLong types.
It does a boundary box, and then does an exact haversine result.
{code}
@Override
public Query rewrite(IndexReader reader) throws IOException {
System.out.println(In rewrite bboxQuery + (bboxQuery == null ? null :
not null));
System.out.println(In rewrite fastgeo + (fastgeo ? true : false));
if (fastgeo) {
Query query = bboxQuery.rewrite(reader);
IndexSearcher searcher = new IndexSearcher(reader);
SpatialWeight w = new SpatialWeight(searcher);
return query;
} else
return bboxQuery != null ? bboxQuery.rewrite(reader) : this;
}
{code}
Assignee: Grant Ingersoll
Summary: Performance improvement for geofilt by doing a bbox
approximation and then Filter (was: FastGeo Filter Feature)
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Grant Ingersoll
Fix For: 4.0
Attachments: SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
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-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-3230:
Attachment: SOLR-3230.patch
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Grant Ingersoll
Fix For: 4.0
Attachments: SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
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-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227008#comment-13227008
]
Bill Bell commented on SOLR-3230:
-
I am pretty new to Filters and all of this. But it appeared that the
SpatialDistanceQuery could just be added to the bbox logic to sequence it. But
I could use a code review.
{code}
if (options.bbox) {
spatial.bboxQuery = result;
return spatial;
} else {
result.add(spatial, BooleanClause.Occur.MUST);
return result;
}
}
{code}
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Grant Ingersoll
Fix For: 4.0
Attachments: SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
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-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227009#comment-13227009
]
Bill Bell commented on SOLR-3230:
-
I did not add a new filter, since it seems a no brainer to always do the bbox
approximation first.
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Grant Ingersoll
Fix For: 4.0
Attachments: SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
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-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227011#comment-13227011
]
Bill Bell commented on SOLR-3230:
-
Ohh. Using exampledate. Score is the distance haversine.
http://localhost:8983/solr/select?q={!func}geodist()fl=score,storesort=score
ascsfield=stored=348fq={!geofilt}pt=45.19614,-93.90341
-- returns 7
http://localhost:8983/solr/select?q={!func}geodist()fl=score,storesort=score
ascsfield=stored=347fq={!geofilt}pt=45.19614,-93.90341
-- returns 6
http://localhost:8983/solr/select?q={!func}geodist()fl=score,storesort=score
ascsfield=stored=347fq={!bbox}pt=45.19614,-93.90341
-- returns 7 (since it is not accurate)
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Grant Ingersoll
Fix For: 4.0
Attachments: SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
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
