[jira] [Commented] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631537#comment-13631537 ] Bill Bell commented on SOLR-4685: - OK. I am uploading 2 test cases. 1. To test without escaping when using the new field. json.fsuffix=_json 2. To test the old way with escaping to make sure nothing was impacted. ant -Dtestcase=JSONWriterTest test JSON response write modification to support RAW JSON Key: SOLR-4685 URL: https://issues.apache.org/jira/browse/SOLR-4685 Project: Solr Issue Type: Improvement Reporter: Bill Bell Attachments: SOLR-4685.patch If the field ends with _json allow the field to return raw JSON. For example the field, office_json -- string I already put into the field raw JSON already escaped. I want it to come with no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-4685: Attachment: SOLR-4685.1.patch JSON response write modification to support RAW JSON Key: SOLR-4685 URL: https://issues.apache.org/jira/browse/SOLR-4685 Project: Solr Issue Type: Improvement Reporter: Bill Bell Attachments: SOLR-4685.1.patch If the field ends with _json allow the field to return raw JSON. For example the field, office_json -- string I already put into the field raw JSON already escaped. I want it to come with no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-4685: Attachment: (was: SOLR-4685.patch) JSON response write modification to support RAW JSON Key: SOLR-4685 URL: https://issues.apache.org/jira/browse/SOLR-4685 Project: Solr Issue Type: Improvement Reporter: Bill Bell Attachments: SOLR-4685.1.patch If the field ends with _json allow the field to return raw JSON. For example the field, office_json -- string I already put into the field raw JSON already escaped. I want it to come with no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4714) Solr server request handler failed
Hardik Upadhyay created SOLR-4714: - Summary: Solr server request handler failed Key: SOLR-4714 URL: https://issues.apache.org/jira/browse/SOLR-4714 Project: Solr Issue Type: Bug Reporter: Hardik Upadhyay When sending a search request via HttpClient post method,solr server fails to parse the query and prints error HttpParser full. The search request was for retrieving 600 entity details ,q:(ent1 ent2 ent3 ... ent600) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Help to unsubscribe
Hi All, Did not mean to bother you all but I could not find a way to unsubscribe. Anyone knows how please email me directly at aswathsrinivasa...@cognizant.commailto:aswathsrinivasa...@cognizant.com. I did send emails to dev-unsubscr...@lucene.apache.orgmailto:dev-unsubscr...@lucene.apache.org like a million + times but no one seems to address the request. Thank you all. Much Thanks, Aswath NS This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful.
[jira] [Updated] (SOLR-4693) Create a collections API to delete/cleanup a Slice
[ https://issues.apache.org/jira/browse/SOLR-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-4693: --- Attachment: SOLR-4693.patch Working patch, minus the test. Will add the tests ASAP. Create a collections API to delete/cleanup a Slice -- Key: SOLR-4693 URL: https://issues.apache.org/jira/browse/SOLR-4693 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Anshum Gupta Attachments: SOLR-4693.patch Have a collections API that cleans up a given shard. Among other places, this would be useful post the shard split call to manage the parent/original slice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4693) Create a collections API to delete/cleanup a Slice
[ https://issues.apache.org/jira/browse/SOLR-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631608#comment-13631608 ] Anshum Gupta commented on SOLR-4693: Also, here's how the API call looks like: http://host/solr/admin/collections?action=DELETESHARDshard=shard_namename=collection_name This only allows for deletion of inactive slices to maintain integrity. Have added a todo to perhaps allow deletion of active slices as long as the HashRange for that slice is serviced by another active slice. Create a collections API to delete/cleanup a Slice -- Key: SOLR-4693 URL: https://issues.apache.org/jira/browse/SOLR-4693 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Anshum Gupta Attachments: SOLR-4693.patch Have a collections API that cleans up a given shard. Among other places, this would be useful post the shard split call to manage the parent/original slice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Research Study: Open source developers on the fence between company and community
Dear ladies and gentlemen, my name is Thomas Zerbach, I'm a research assistant at the University of Koblenz-Landau (Germany) currently working on an empirical research study which revolves around the job situation of (professional) open source developers. The goal of the study is to gain insights on the effect of developers' double commitment to the open source community and the organization. The study already received support by several organizations including the Open Source Business Foundation (OSBF), the European Commission's Joinup project and various open source projects (e.g. Eclipse) and experts (e.g. former Open Source Director at Oracle Gilles Gravier)! I am contacting you with the hope of getting any kind of support in order to reach a bigger target audience that could contribute to the research. Here are some main facts about the study: _Who is the target group?_ The study is aimed at employed software developers who also work with open source code and therefore are to some extent dependant on the open source community. _Why should developers participate?_ 1. They can support social projects and a startup company at the same time! As an incentive, the University of Koblenz-Landau offers participants the opportunity to donate real money invested by the University to social projects after completing the survey. This offer is part of a collaboration with the startup company socialfunders, which specializes on corporate giving processes. More information on the socialfunders can be found here: https://www.socialfunders.org/. 2. They can make their voice heard! The research study aims at deriving managerial implications for organizations to improve their employees' job situation. Participants can also gain insights in the situation of fellow open source developers if they want to receive a rehashed version of the research results after the completion of the study. _How much effort is required?_ Only about 10 minutes of their time. All information will of course be treated anonymously and solely be used for scientific purposes. _Link to the research study:_ http://ww2.unipark.de/uc/kb_uni_koblenz_kilian_ls/d20b/ I hope I was able to catch your interest. If you can think of a way how to support me with my research (e.g. by forwarding this message or incorporating this information in a newsletter/ internal forum) or if you have any questions regarding the research study feel free to contact me. I am looking forward to hearing from you! Best Regards, Thomas Zerbach -- E-Mail: tzerb...@uni-koblenz.de mailto:tzerb...@uni-koblenz.de Wissenschaftlicher Mitarbeiter Universität Koblenz-Landau Lehrstuhl für Informationsmanagement und Organisation Universitätsstr. 1 56070 Koblenz www.uni-koblenz.de http://www.uni-koblenz.de/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4715) CloudSolrServer does not provide support for setting XmlResponseWriter
Hardik Upadhyay created SOLR-4715: - Summary: CloudSolrServer does not provide support for setting XmlResponseWriter Key: SOLR-4715 URL: https://issues.apache.org/jira/browse/SOLR-4715 Project: Solr Issue Type: Bug Reporter: Hardik Upadhyay CloudSolrServer as well as LBHttpSolrServer does not allow to set XMLResponseWriter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4774) Add FieldComparator that allows sorting parent docs based on field inside the child docs
[ https://issues.apache.org/jira/browse/LUCENE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated LUCENE-4774: -- Fix Version/s: 5.0 Add FieldComparator that allows sorting parent docs based on field inside the child docs Key: LUCENE-4774 URL: https://issues.apache.org/jira/browse/LUCENE-4774 Project: Lucene - Core Issue Type: New Feature Components: modules/join Reporter: Martijn van Groningen Assignee: Martijn van Groningen Fix For: 5.0, 4.3 Attachments: LUCENE-4774.patch, LUCENE-4774.patch, LUCENE-4774.patch A field comparator for sorting block join parent docs based on the a field in the associated child docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4774) Add FieldComparator that allows sorting parent docs based on field inside the child docs
[ https://issues.apache.org/jira/browse/LUCENE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen resolved LUCENE-4774. --- Resolution: Fixed Committed to trunk and 4x branche. Add FieldComparator that allows sorting parent docs based on field inside the child docs Key: LUCENE-4774 URL: https://issues.apache.org/jira/browse/LUCENE-4774 Project: Lucene - Core Issue Type: New Feature Components: modules/join Reporter: Martijn van Groningen Assignee: Martijn van Groningen Fix For: 5.0, 4.3 Attachments: LUCENE-4774.patch, LUCENE-4774.patch, LUCENE-4774.patch A field comparator for sorting block join parent docs based on the a field in the associated child docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Help to unsubscribe
It's all automated, there's no manual intervention. You have to use the _exact_ e-mail you subscribed with. Here's a page of tips: https://wiki.apache.org/solr/Unsubscribing%20from%20mailing%20lists That process should work, let us know if it doesn't. Best Erick On Mon, Apr 15, 2013 at 4:52 AM, aswathsrinivasa...@cognizant.com wrote: Hi All, Did not mean to bother you all but I could not find a way to unsubscribe. Anyone knows how please email me directly at aswathsrinivasa...@cognizant.com. I did send emails to dev-unsubscr...@lucene.apache.org like a million + times but no one seems to address the request. Thank you all. Much Thanks, Aswath NS This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Help to unsubscribe
I have added a comment to that wiki page about not using HTML, as that can get caught in the spam filters. Upayavira On Mon, Apr 15, 2013, at 11:57 AM, Erick Erickson wrote: It's all automated, there's no manual intervention. You have to use the _exact_ e-mail you subscribed with. Here's a page of tips: https://wiki.apache.org/solr/Unsubscribing%20from%20mailing%20lists That process should work, let us know if it doesn't. Best Erick On Mon, Apr 15, 2013 at 4:52 AM, aswathsrinivasa...@cognizant.com wrote: Hi All, Did not mean to bother you all but I could not find a way to unsubscribe. Anyone knows how please email me directly at aswathsrinivasa...@cognizant.com. I did send emails to dev-unsubscr...@lucene.apache.org like a million + times but no one seems to address the request. Thank you all. Much Thanks, Aswath NS This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. - 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] [Commented] (LUCENE-4924) Make DocIdSetIterator.docID() return -1 when not positioned
[ https://issues.apache.org/jira/browse/LUCENE-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631697#comment-13631697 ] Adrien Grand commented on LUCENE-4924: -- I plan to commit soon and backport everything to 4.x but the changes entry and the DocIdSetIterator.docID() javadoc change. Make DocIdSetIterator.docID() return -1 when not positioned --- Key: LUCENE-4924 URL: https://issues.apache.org/jira/browse/LUCENE-4924 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 Attachments: LUCENE-4924.patch, LUCENE-4924.patch, LUCENE-4924.patch Today DocIdSetIterator.docID() can either return -1 or NO_MORE_DOCS when the enum is not positioned. I would like to only allow it to return -1 so that we can have better assertions. (This proposal is for trunk only.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4693) Create a collections API to delete/cleanup a Slice
[ https://issues.apache.org/jira/browse/SOLR-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-4693: --- Assignee: Shalin Shekhar Mangar Create a collections API to delete/cleanup a Slice -- Key: SOLR-4693 URL: https://issues.apache.org/jira/browse/SOLR-4693 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Anshum Gupta Assignee: Shalin Shekhar Mangar Attachments: SOLR-4693.patch Have a collections API that cleans up a given shard. Among other places, this would be useful post the shard split call to manage the parent/original slice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4911) Missing word cela in conf/lang/stopwords_fr.txt
[ https://issues.apache.org/jira/browse/LUCENE-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631706#comment-13631706 ] Pierre Kobylanski commented on LUCENE-4911: --- Thanks Missing word cela in conf/lang/stopwords_fr.txt - Key: LUCENE-4911 URL: https://issues.apache.org/jira/browse/LUCENE-4911 Project: Lucene - Core Issue Type: Improvement Affects Versions: 4.2 Reporter: Pierre Kobylanski Assignee: Adrien Grand Priority: Trivial Attachments: stopwords_fr.txt.patch Original Estimate: 10m Remaining Estimate: 10m NB: Not sure this defect is assigned to the right component. In file example/solr/collection1/conf/lang/stopwords_fr.txt, there is the word celà. Though incorrect in French (cf http://fr.wiktionary.org/wiki/cel%C3%A0), it's common, but we may also add the correct spelling (e.g. cela, whitout accent) to that stopwords list. Another thing: I noticed that celà is the only word of the list followed by an unbreakable space. Is that wanted? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4566) clusterstate#getSlices and getSlicesMap should always return all slices.
[ https://issues.apache.org/jira/browse/SOLR-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631733#comment-13631733 ] Shalin Shekhar Mangar commented on SOLR-4566: - The attached patch was committed to trunk and branch_4x along with the shard split feature. If people are happy with the API proposed in the patch then we can mark this issue as resolved. clusterstate#getSlices and getSlicesMap should always return all slices. Key: SOLR-4566 URL: https://issues.apache.org/jira/browse/SOLR-4566 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: SOLR-4566.patch I'm not sure I really like this getSlices vs getAllSclies - it's kind of easy to get in trouble right now I think. Some spots that we clearly want to call getAllSlices got left with getSlices. It's almost surprising that getSlices only returns active replicas - it should probably at least be called getSlicesWithActive or something more explicit. But for the first step, we should just fix the various mis calls. There are a couple problems around the mis calls, the most severe probably being that you can lose shards that are not active from the clusterstate.json given the right races. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4566) clusterstate#getSlices and getSlicesMap should always return all slices.
[ https://issues.apache.org/jira/browse/SOLR-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-4566. --- Resolution: Fixed clusterstate#getSlices and getSlicesMap should always return all slices. Key: SOLR-4566 URL: https://issues.apache.org/jira/browse/SOLR-4566 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: SOLR-4566.patch I'm not sure I really like this getSlices vs getAllSclies - it's kind of easy to get in trouble right now I think. Some spots that we clearly want to call getAllSlices got left with getSlices. It's almost surprising that getSlices only returns active replicas - it should probably at least be called getSlicesWithActive or something more explicit. But for the first step, we should just fix the various mis calls. There are a couple problems around the mis calls, the most severe probably being that you can lose shards that are not active from the clusterstate.json given the right races. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4928) Compressed stored fields: make the maximum number of docs in a chunk configurable
[ https://issues.apache.org/jira/browse/LUCENE-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-4928. -- Resolution: Fixed Compressed stored fields: make the maximum number of docs in a chunk configurable - Key: LUCENE-4928 URL: https://issues.apache.org/jira/browse/LUCENE-4928 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.3 Attachments: LUCENE-4928.patch When documents are very small (a few bytes), there can be so many of them in a single chunk that merging can become very slow. Making the maximum number of documents per chunk configurable could help. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4693) Create a collections API to delete/cleanup a Slice
[ https://issues.apache.org/jira/browse/SOLR-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631752#comment-13631752 ] Yonik Seeley commented on SOLR-4693: bq. Have added a todo to perhaps allow deletion of active slices as long as the HashRange for that slice is serviced by another active slice. And we should allow deletion if the slice has no hash range (i.e. custom sharding)? Create a collections API to delete/cleanup a Slice -- Key: SOLR-4693 URL: https://issues.apache.org/jira/browse/SOLR-4693 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Anshum Gupta Assignee: Shalin Shekhar Mangar Attachments: SOLR-4693.patch Have a collections API that cleans up a given shard. Among other places, this would be useful post the shard split call to manage the parent/original slice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-3251: - Attachment: SOLR-3251.patch Patch with the following changes: * Schema is now effectively immutable: requests see the same schema snapshot for their lifetimes. * ManagedIndexSchema.addFields() allows for multiple fields to be added at once, though only the single-field REST API is provided at this point. * Only new field additions are allowed: addFields() fails if getFieldOrNull() returns non-null for any of the given new fields. * SchemaCodecFactory and SchemaSimilarityFactory don't change codec and similarity when the schema is swapped out: instead they refer to the latest version they have been inform()'d about. * Multi-core shared schemas are now handled: the old schema is removed from the schema cache, the new schema is added to the schema cache, and the new schema replaces the old schema in all active cores. [~rcmuir], I'd appreciate your review of these changes. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Assignee: Steve Rowe Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4924) Make DocIdSetIterator.docID() return -1 when not positioned
[ https://issues.apache.org/jira/browse/LUCENE-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631757#comment-13631757 ] Yonik Seeley commented on LUCENE-4924: -- +1, looks good! Make DocIdSetIterator.docID() return -1 when not positioned --- Key: LUCENE-4924 URL: https://issues.apache.org/jira/browse/LUCENE-4924 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 Attachments: LUCENE-4924.patch, LUCENE-4924.patch, LUCENE-4924.patch Today DocIdSetIterator.docID() can either return -1 or NO_MORE_DOCS when the enum is not positioned. I would like to only allow it to return -1 so that we can have better assertions. (This proposal is for trunk only.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4693) Create a collections API to delete/cleanup a Slice
[ https://issues.apache.org/jira/browse/SOLR-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631764#comment-13631764 ] Anshum Gupta commented on SOLR-4693: bq. And we should allow deletion if the slice has no hash range (i.e. custom sharding)? Makes sense, will add that as a todo. But for now, (primarily for shard split cleanup) we'll just let a user delete a Slice as long as the Slice is inactive. Create a collections API to delete/cleanup a Slice -- Key: SOLR-4693 URL: https://issues.apache.org/jira/browse/SOLR-4693 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Anshum Gupta Assignee: Shalin Shekhar Mangar Attachments: SOLR-4693.patch Have a collections API that cleans up a given shard. Among other places, this would be useful post the shard split call to manage the parent/original slice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4924) Make DocIdSetIterator.docID() return -1 when not positioned
[ https://issues.apache.org/jira/browse/LUCENE-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-4924. -- Resolution: Fixed Thank you Robert and Yonik! Make DocIdSetIterator.docID() return -1 when not positioned --- Key: LUCENE-4924 URL: https://issues.apache.org/jira/browse/LUCENE-4924 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 Attachments: LUCENE-4924.patch, LUCENE-4924.patch, LUCENE-4924.patch Today DocIdSetIterator.docID() can either return -1 or NO_MORE_DOCS when the enum is not positioned. I would like to only allow it to return -1 so that we can have better assertions. (This proposal is for trunk only.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631773#comment-13631773
]
Yonik Seeley commented on SOLR-3251:
One thing I noticed quickly is there a reason this is synchronized?
{code}
//Run the callbacks on SchemaAware now that everything else is done
synchronized (schemaAware) {
for (SchemaAware aware : schemaAware) {
aware.inform(this);
}
}
{code}
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Steve Rowe
Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631786#comment-13631786
]
Steve Rowe commented on SOLR-3251:
--
Thanks for taking a look, Yonik.
{quote}
One thing I noticed quickly is there a reason this is synchronized?
{code:java}
//Run the callbacks on SchemaAware now that everything else is done
synchronized (schemaAware) {
for (SchemaAware aware : schemaAware) {
aware.inform(this);
}
}
{code}
{quote}
No, that's a vestige from when I had thought that access to the schema aware
collection needed to be synchronized, I forgot to clean it up here. I'll
remove the synchronization.
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Steve Rowe
Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631807#comment-13631807
]
Robert Muir commented on SOLR-3251:
---
Hi Steve, I took a quick glance. One thing I don't quite understand:
{quote}
SchemaCodecFactory and SchemaSimilarityFactory don't change codec and
similarity when the schema is swapped out: instead they refer to the latest
version they have been inform()'d about.
{quote}
Can you elaborate on this (maybe just some code comments about which inform()
gets called when)? I don't understand why there should be 2 inform methods or
what its doing... ?
Is the idea that these classes just need to be core-aware instead? And the
SchemaAware interface is pretty much useless, except its being used now only as
a marker to detect that the sim/codec understands properties on schema elements?
Can we do something to eliminate the two inform methods?
{quote}
Schema is now effectively immutable: requests see the same schema snapshot for
their lifetimes.
{quote}
well, except it seems for similarity (on indexsearcher)... which could be
looking at the latest copy?
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Steve Rowe
Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-3251: --- Fix Version/s: 4.3 dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Assignee: Steve Rowe Fix For: 4.3 Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631814#comment-13631814
]
Steve Rowe commented on SOLR-3251:
--
{quote}
bq. SchemaCodecFactory and SchemaSimilarityFactory don't change codec and
similarity when the schema is swapped out: instead they refer to the latest
version they have been inform()'d about.
Can you elaborate on this (maybe just some code comments about which inform()
gets called when)? I don't understand why there should be 2 inform methods or
what its doing... ?
{quote}
When a new schema with added fields is produced, the {{inform(schema)}}
SchemaAware variant is called - this is not just a marker interface.
The {{inform(core)}} SolrCoreAware variant is called when a new core is
instantiated, including on {{SolrCore.reload()}}. Looking now, though, I can
see that in the SolrCore ctor, a new codec is pulled from the CodecFactory, so
{{inform(core)}} isn't needed for it.
For similarity, which is hosted on the IndexSchema, {{inform(core)}} won't have
any effect.
So it looks like the right thing to do is remove SolrCoreAware from both
factories. I'll do that. SchemaAware needs to remain, though, so that the
schema references can track the latest versions.
{quote}
bq. Schema is now effectively immutable: requests see the same schema snapshot
for their lifetimes.
well, except it seems for similarity (on indexsearcher)... which could be
looking at the latest copy?
{quote}
Yes, that's right: similarity and codec both will be looking at the latest copy.
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Steve Rowe
Fix For: 4.3
Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release PyLucene 4.2.1
On Apr 15, 2013, at 3:52, Michael McCandless luc...@mikemccandless.com wrote: I'm having trouble on an Ubuntu 12.10 box, using Java 1.7_07 and Python 2.7.3. I was able to build and install both JCC and PyLucene, apparently successfully. I can import lucene in Python and print lucene.VERSION and confirm it's 4.2.1. lucene.initVM(lucene.CLASSPATH) succeeds. Yet, there are no Lucene classes in the lucene module? When I print dir(lucene) I just get this: ['CLASSPATH', 'ConstVariableDescriptor', 'FinalizerClass', 'FinalizerProxy', 'InvalidArgsError', 'JArray', 'JArray_bool', 'JArray_byte', 'JArray_char', 'JArray_double', 'JArray_float', 'JArray_int', 'JArray_long', 'JArray_object', 'JArray_short', 'JArray_string', 'JCCEnv', 'JCC_VERSION', 'JObject', 'JavaError', 'PrintWriter', 'StringWriter', 'VERSION', '__builtins__', '__dir__', '__doc__', '__file__', '__name__', '__package__', '__path__', '_lucene', 'findClass', 'getVMEnv', 'initVM', 'makeClass', 'makeInterface', 'os', 'sys'] Am I missing something silly...? Shouldn't Lucene's classes (eg FSDirectory) be visible in globals() in the lucene module? The one big change on the PyLucene side is that now Lucene classes are in a package structure that mirrors the Java one. Thus, to get FSDirectory you now need to: import lucene from org.apache.lucene.store import FSDirectory Besides providing initVM() and a few other things such as JArray, importing lucene also installs the org package tree. Andi.. Mike McCandless http://blog.mikemccandless.com On Sat, Apr 13, 2013 at 5:51 PM, Andi Vajda va...@apache.org wrote: It looks like the time has finally come for a PyLucene 4.x release ! The PyLucene 4.2.1-0 release tracking the recent release of Apache Lucene 4.2.1 is ready. A release candidate is available from: http://people.apache.org/~vajda/staging_area/ A list of changes in this release can be seen at: http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_2/CHANGES PyLucene 4.2.1 is built with JCC 2.16 included in these release artifacts: http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES A list of Lucene Java changes can be seen at: http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_2_1/lucene/CHANGES.txt Please vote to release these artifacts as PyLucene 4.2.1-0. Thanks ! Andi.. ps: the KEYS file for PyLucene release signing is at: http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS http://people.apache.org/~vajda/staging_area/KEYS pps: here is my +1
[jira] [Created] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
Robert Muir created LUCENE-4934: --- Summary: AssertingIndexSearcher should do basic QueryUtils/etc checks on every query Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4710) You cannot delete a collection fully from ZooKeeper unless all nodes are up and functioning correctly.
[ https://issues.apache.org/jira/browse/SOLR-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4710: -- Attachment: SOLR-4710.patch This patch has the OverseerCollectionProcessor send a new remove collection cmd to the Overseer work queue after asking each SolrCore to unload itself. You cannot delete a collection fully from ZooKeeper unless all nodes are up and functioning correctly. -- Key: SOLR-4710 URL: https://issues.apache.org/jira/browse/SOLR-4710 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: SOLR-4710.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631823#comment-13631823 ] Yonik Seeley commented on SOLR-3251: One super-minor concurrency issue: the check to see if a schema is mutable should be within the optimistic concurrency retry loop, else fields could be added to a schema that was just marked as immutable. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Assignee: Steve Rowe Fix For: 4.3 Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631824#comment-13631824 ] Adrien Grand commented on LUCENE-4934: -- +1 AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4710) You cannot delete a collection fully from ZooKeeper unless all nodes are up and functioning correctly.
[ https://issues.apache.org/jira/browse/SOLR-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631826#comment-13631826 ] Mark Miller commented on SOLR-4710: --- In the future, if we started shipping with no cores out of the box and required use of the collections api, the overseer could be more intelligent here I think - for example, if you removed a collection and then some instances came back that still had it, the Overseer could tell those instances to unload now stale SolrCores rather than starting them. You cannot delete a collection fully from ZooKeeper unless all nodes are up and functioning correctly. -- Key: SOLR-4710 URL: https://issues.apache.org/jira/browse/SOLR-4710 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: SOLR-4710.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4934: Attachment: LUCENE-4934.patch Here's a start just doing the simplest check. I am currently running tests fixing the bugs this one found... I'm gonna see if we can do the explanations test though (at some point we will hit bugs in spans/payloads like LUCENE-4219) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631830#comment-13631830 ] Steve Rowe commented on SOLR-3251: -- bq. One super-minor concurrency issue: the check to see if a schema is mutable should be within the optimistic concurrency retry loop, else fields could be added to a schema that was just marked as immutable. Right now ManagedIndexSchemaFactory's mutability setting comes from SolrConfig, and is only changeable on SolrConfig change and reload, so neither mutable-immutable nor immutable-mutable should be possible. Or maybe I don't understand how SolrConfig works? dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Assignee: Steve Rowe Fix For: 4.3 Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631834#comment-13631834 ] Yonik Seeley commented on SOLR-3251: bq. Right now ManagedIndexSchemaFactory's mutability setting comes from SolrConfig, and is only changeable on SolrConfig change and reload, so neither mutable-immutable nor immutable-mutable should be possible. Ah, ok - I had assumed it was on the schema itself. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Assignee: Steve Rowe Fix For: 4.3 Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631833#comment-13631833 ] Robert Muir commented on LUCENE-4934: - There are hashcode/equals bugs in DrillDownQuery :) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631840#comment-13631840 ] Steve Rowe commented on SOLR-3251: -- bq. Ah, ok - I had assumed it was on the schema itself. Well, it is a boolean on ManagedIndexSchema, but there's no setter, only a getter, and the ManagedIndexSchema ctor, which is only called from the factory, is the only place it's set. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Assignee: Steve Rowe Fix For: 4.3 Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4934: Attachment: LUCENE-4934.patch updated patch: now the next bug to fix is hashcode/equals in DrillSidewaysQuery. I don't know why it throws UOE today... we can't do stuff like this. AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch, LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4628) Solr 4.2 Admin UI
[
https://issues.apache.org/jira/browse/SOLR-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631849#comment-13631849
]
Stefan Matheis (steffkes) commented on SOLR-4628:
-
I thought we had a {{title}}-attribute in use which should at least display the
full path on mouseover .. but actually this is not the case :/ Though i'm not
sure if that is really a major .. are you actually working on this? If so,
would you mind attaching a current version as a patch to this issue?
Solr 4.2 Admin UI
-
Key: SOLR-4628
URL: https://issues.apache.org/jira/browse/SOLR-4628
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.2
Environment: Intel PC + Win7 64 + Tomcat 6 + 19-inch 4:3 screen
Reporter: cozybreeze
Labels: 4.2, admin, gui, solr
The new Admin web GUI has too-compact column for normal-width screen, e.g. in
the dashboard, if the directory is a long path, it will suppress the display
and replace the trailing part with '...' and there is no way to see the full
path.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Packaging question
I was trying to make EmbeddedSolrServer work from a distro recently and ran across a series of ClassNotFound exceptions. It works fine if I build the code then path to solr home/core/lib, which isn't present in the distro. Is this intentional? Or am I overlooking the obvious yet again? I usually compile everything I'm trying to work on from source code, so it might have always been like this... Thanks, Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631870#comment-13631870 ] Shawn Heisey commented on SOLR-4470: +1 on getting this into Solr. I personally don't need this, but I see lots of help requests on the mailing list and IRC channel asking how can I secure Solr? The current general answer (4.2.1) is that they can't. Exceptions are: 1) If the only inter-node communication they have enabled is replication, which has supported basic auth since 1.4.0. There is some anecdotal evidence that basic auth for replication may be broken in 4.2 and/or 4.2.1. 2) Putting an authenticating proxy in front of Solr so it's the only way for clients to access it. Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Labels: authentication, https, solrclient, solrcloud, ssl Fix For: 4.3 Attachments: SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4934: Attachment: LUCENE-4934.patch updated patch: fixes some more equals/hashcode bugs. I also implemented the assert differently: we check both before rewrite() and after. AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631884#comment-13631884 ] Robert Muir commented on LUCENE-4934: - 3 more queries with bugs i still havent fixed: [junit4:junit4] Tests with failures: [junit4:junit4] - org.apache.lucene.queryparser.xml.TestParser.testLikeThisQueryXML [junit4:junit4] - org.apache.lucene.queryparser.xml.TestParser.testBoostingQueryXML [junit4:junit4] - org.apache.lucene.queryparser.xml.TestParser.testFuzzyLikeThisQueryXML Its a little disturbing that tests in lucene/queries arent finding these problems, only a queryparser test. Maybe they arent using newSearcher. AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 400 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/400/ Java: 64bit/jdk1.7.0 -XX:+UseParallelGC All tests passed Build Log: [...truncated 9336 lines...] [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home/jre/bin/java -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=3D6E6AD0413C05C1 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dfile.encoding=US-ASCII -classpath
[jira] [Commented] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631908#comment-13631908 ] Uwe Schindler commented on LUCENE-4934: --- +1, I also like the Term.toString() method :-) We may use a similar approach in Solr's AnalysisRequestHandler when completely binary terms are generated (currently it prints the raw binary term and the string rep next to each other). If the latter fails, it should only return the binary term in the NämedList. AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4934: Attachment: LUCENE-4934.patch OK updated patch. I think i fixed the big issues in all these equals/hashcodes. BlockJoin should be revisited (in another issue: please). Its doing complicated stuff like equals based on unrewritten-query, I think this is wrong (e.g. in the case of a MTQ query rewritten from anotehr reader). But i dont want to fix this here. I want to commit this to make some progress and then look at trying to improve the check (e.g. explains would be a nice step) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4456) Admin UI: Displays dashboard even if Solr is down
[ https://issues.apache.org/jira/browse/SOLR-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-4456: Attachment: SOLR-4456.patch Updated Patch. Now, if the Layer appears, the Browser will be checking in the background if the server is available again. (the background check uses a exponential function to avoid hammering the server) When that's the case, all the bad-red things will change into friendly-green ones, telling you that the instance is available again und that you should reload the page. While playing around with it, i though about automatically reloading the page .. but i'm not really sure if that's clear what happend from a users perspective? If you're not sitting in front of the browser (especially this tab) and you view it again and the layer is done w/o you doing anything? Admin UI: Displays dashboard even if Solr is down - Key: SOLR-4456 URL: https://issues.apache.org/jira/browse/SOLR-4456 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1 Reporter: Jan Høydahl Assignee: Stefan Matheis (steffkes) Fix For: 4.3 Attachments: SOLR-4456.patch, SOLR-4456.patch 1. Run Solr and bruing up the Admin dashboard 2. Stop Solr 3. Click around the Admin GUI. It apparently works, but displays a spinning wheel for most panels 4. Click on Dashboard. An old cached dashboard is displayed What should happen is that once connection to Solr is lost, the whole Admin UI displays a large red box CONNECTION LOST or something :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631953#comment-13631953 ] Michael McCandless commented on LUCENE-4934: +1 AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4934) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query
[ https://issues.apache.org/jira/browse/LUCENE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631955#comment-13631955 ] Uwe Schindler commented on LUCENE-4934: --- bq. I also implemented the assert differently: we check both before rewrite() and after. Hey, that was my idea to move that into IS.rewrite() :-) AssertingIndexSearcher should do basic QueryUtils/etc checks on every query --- Key: LUCENE-4934 URL: https://issues.apache.org/jira/browse/LUCENE-4934 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch, LUCENE-4934.patch We can start with QueryUtils.check(query): which does some basic hashcode/equals checks. Ideally we'd strengthen the checks as we fix problems: e.g. add explanations verifications (checkExplanations) and then finally the more intense check() that does more verifications with deleted docs/next/advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2943) DIHCacheWriter DIHCacheProcessor (entity processor)
[ https://issues.apache.org/jira/browse/SOLR-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-2943: - Attachment: SOLR-2943.patch updated patch for Trunk. DIHCacheWriter DIHCacheProcessor (entity processor) - Key: SOLR-2943 URL: https://issues.apache.org/jira/browse/SOLR-2943 Project: Solr Issue Type: New Feature Components: contrib - DataImportHandler Affects Versions: 4.0-ALPHA Reporter: James Dyer Priority: Minor Fix For: 4.3 Attachments: SOLR-2943.patch, SOLR-2943.patch, SOLR-2943.patch This is a spin-off of SOLR-2382. Currently DIH requires users to retrieve, join and index all data for a full or delta update in one big step. This issue is to allow us to break this into individual steps. The idea is to have multiple data-config.xml files, some of which retrieve and cache data while others join and index data. This is useful when Solr Records are a conglomeration of several data sources. With this feature, each data source can be retrieved and cached separately. Once all data sources have been retrieved, they can be joined and indexed in a final step. When doing a delta update, only the data sources that change need to have their caches updated (or frequently-changing data can remain un-cached while caching the more static data). This is particularly useful in light of the fact that Lucene/Solr cannot do a true update operation. DIH Caches also provide a handy way to archive source data for which there is no stable system-of-record. Implementation Details: - The DIHCacheWriter allows us to write the final (root entity) DIH output to a DIHCache rather than to Solr. Caches can be created from scratch (full-update) or existing caches can be modified (delta-update). - The DIHCacheProcessor is an Entity Processor that reads a DIHCache. This Entity Processor can be used for both Root Entities and Child Entities. Cached data can be read back, joined to other Entities and indexed. - Both DIHCacheWriter and DIHCacheProcessor support partitioning. DIHCacheWriter can write to a partitioned cache while DIHCacheProcessor can read back a particular partition. This can be handy when indexing to multiple shards. - This patch is 100% stand-alone from the rest of DIH, so while users can patch and rebuild the DIH .jar file to include these classes, it is unnecessary. To use this functionality, simply include the code here in the classpath. (ex: in SOLR_HOME/lib) - In addition to this patch, a persistent cache implementation is required. - See SOLR-2948 for a DIH Cache Implementation built on Lucene (no additional dependencies). - See SOLR-2613 for a DIH Cache Implementation backed with BDB-JE (we use this in Production). - Other Cache Implementations (hopefully) will be developed in the future and become available for general use. - This patch includes extensive unit tests. A MockDIHCache that supports persistence and delta updates facilitates the tests. Do not attempt to use MockDIHCache for anything other than testing or as a reference for developing your own DIHCache implementations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2948) DIH Cache backed w/Lucene
[ https://issues.apache.org/jira/browse/SOLR-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-2948: - Attachment: SOLR-2948.patch Updated patch for trunk. There is a test bug in that the delta-update tests fail when starting the delta update. Seems there is some type of security violation when trying to re-open dataimport.properties. This only happens when running through ant, not through eclipse. DIH Cache backed w/Lucene - Key: SOLR-2948 URL: https://issues.apache.org/jira/browse/SOLR-2948 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 4.0-ALPHA Reporter: James Dyer Priority: Minor Fix For: 4.3 Attachments: SOLR-2948.patch, SOLR-2948.patch This is a DIH Cache Implementation that supports persistence and delta updates on the cache. The cache is backed by a stand-alone Lucene index. By requiring no additional dependencies, this allows users to easily use the DIH Cache persistence functionality (see SOLR-2943). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3838) Multiple filter queries are not supported in the Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3838: Attachment: SOLR-3838.patch Like this Jack? If the functionality is okay, that can be applied to other fields as well :) Only have to know, which ones .. Multiple filter queries are not supported in the Solr Admin Query UI Key: SOLR-3838 URL: https://issues.apache.org/jira/browse/SOLR-3838 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Reporter: Jack Krupansky Attachments: SOLR-3838.patch The Solr Admin Query UI has only a single fq input field, which does not permit the user to enter multiple filter query parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4456) Admin UI: Displays dashboard even if Solr is down
[ https://issues.apache.org/jira/browse/SOLR-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-4456: Attachment: SOLR-4456.patch Admin UI: Displays dashboard even if Solr is down - Key: SOLR-4456 URL: https://issues.apache.org/jira/browse/SOLR-4456 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1 Reporter: Jan Høydahl Assignee: Stefan Matheis (steffkes) Fix For: 4.3 Attachments: SOLR-4456.patch, SOLR-4456.patch, SOLR-4456.patch 1. Run Solr and bruing up the Admin dashboard 2. Stop Solr 3. Click around the Admin GUI. It apparently works, but displays a spinning wheel for most panels 4. Click on Dashboard. An old cached dashboard is displayed What should happen is that once connection to Solr is lost, the whole Admin UI displays a large red box CONNECTION LOST or something :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-3251:
-
Attachment: SOLR-3251.patch
Patch:
SchemaSimilarityFactory and SchemaCodecFactory now implement only SolrCoreAware
- SchemaAware alone was insufficient; you were right, Robert.
bq. Can we do something to eliminate the two inform methods?
I think the SolrCoreAware one is necessary - I couldn't see how otherwise to
pass in the SolrCore.
I added a POST REST method allowing multiple fields to be added at once, at
{{/schema/fields}}.
I think it's ready.
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Steve Rowe
Fix For: 4.3
Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
SOLR-3251.patch, SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632041#comment-13632041 ] Sam Kass commented on SOLR-3854: While Alexey's patch is admirably succinct, Sami's patch allows setting the protocol via the solr.xml file where all the other settings are stored, as well as getting rid of a bunch of arbitrary comparisons to the explicit http string, so seems preferable to me. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.3 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4702) Velocity templates not rendering spellcheck suggestions correctly
[
https://issues.apache.org/jira/browse/SOLR-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632118#comment-13632118
]
Mark Bennett commented on SOLR-4702:
Hi Erik,
Thanks.
Two options we might consider:
1: I didn't see a for loop, and in some cases there could be multiple
collations?
2: When debugging, seeing the raw suggestions, prior to collation filtering,
can be nice. Though I'm not sure if that's a good fit for these templates or
not. If we come back and add more options, maybe a
showRawSpellingSuggestions=true|FALSE might be nice.
Velocity templates not rendering spellcheck suggestions correctly
-
Key: SOLR-4702
URL: https://issues.apache.org/jira/browse/SOLR-4702
Project: Solr
Issue Type: Bug
Components: contrib - Velocity
Affects Versions: 4.2
Reporter: Mark Bennett
Assignee: Erik Hatcher
Attachments: SOLR-4702.patch, SOLR-4702.patch, SOLR-4702.patch
The spellcheck links, AKA Did you mean, aren't rendered correctly.
Instead of just having the corrected words, they have some .toString
gibberish because the object being serialized is too high up in the tree.
This breaks both the link text displayed to the user, and the href used for
the anchor tag.
Example:
Search for electronicss OR monitor and you get:
Did you mean {collationQuery=electronics OR
monitor,hits=14,misspellingsAndCorrections={electronicss=electronics,monitor=monitor}}?
But you should just see:
Did you mean electronics OR monitor? (with hyperlinked electronics OR
monitor)
The actual query submitted by those links is similarly broken. Possibly the
templates were developed before collation was added and/or enabled by default.
To see this bug at all with the example configs and docs you'll need to have
applied SOLR-4680 or SOLR-4681 against 4.2 or trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-4504) Empty results from IndexSearcher.searchAfter() when sorting by FunctionValues
[ https://issues.apache.org/jira/browse/LUCENE-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reopened LUCENE-4504: - While adding more assertions to the tests, i noticed i somehow screwed up the backport here... this bugfix and test were never backported to 4.1. Empty results from IndexSearcher.searchAfter() when sorting by FunctionValues - Key: LUCENE-4504 URL: https://issues.apache.org/jira/browse/LUCENE-4504 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 4.0 Reporter: TomShally Priority: Minor Fix For: 4.1, 5.0 Attachments: LUCENE-4504.patch, LUCENE-4504.patch, Lucene4504Test.java IS.searchAfter() always returns an empty result when using FunctionValues for sorting. The culprit is ValueSourceComparator.compareDocToValue() returning -1 when it should return +1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4504) Empty results from IndexSearcher.searchAfter() when sorting by FunctionValues
[ https://issues.apache.org/jira/browse/LUCENE-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4504. - Resolution: Fixed Fix Version/s: (was: 4.1) 4.3 Empty results from IndexSearcher.searchAfter() when sorting by FunctionValues - Key: LUCENE-4504 URL: https://issues.apache.org/jira/browse/LUCENE-4504 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 4.0 Reporter: TomShally Priority: Minor Fix For: 5.0, 4.3 Attachments: LUCENE-4504.patch, LUCENE-4504.patch, Lucene4504Test.java IS.searchAfter() always returns an empty result when using FunctionValues for sorting. The culprit is ValueSourceComparator.compareDocToValue() returning -1 when it should return +1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.6.0_43) - Build # 2709 - Failure!
: REGRESSION: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication : : Error Message: : timed out waiting for collection1 startAt time to exceed: Sun Apr 14 11:48:20 ECT 2013 : : Stack Trace: : java.lang.AssertionError: timed out waiting for collection1 startAt time to exceed: Sun Apr 14 11:48:20 ECT 2013 : at __randomizedtesting.SeedInfo.seed([F2791E68547FFE97:29D21EAE51579724]:0) : at org.junit.Assert.fail(Assert.java:93) : at org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1472) : at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:776) I checked the logs and confirmed that this is a manifestation of SOLR-4709. Miller: do you understand what's going on here with the getNewIndexDir() check in SolrCore.reload? Is there a bug here, or should SnapPuler have some retry logic for the core reload? https://issues.apache.org/jira/browse/SOLR-4709 [junit4:junit4] 1 ERROR - 2013-04-14 16:48:20.864; org.apache.solr.core.CoreContainer; Unable to reload core: collection1 [junit4:junit4] 1 org.apache.solr.common.SolrException: Index locked for write for core collection1 [junit4:junit4] 1at org.apache.solr.core.SolrCore.init(SolrCore.java:821) [junit4:junit4] 1at org.apache.solr.core.SolrCore.reload(SolrCore.java:408) [junit4:junit4] 1at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1108) [junit4:junit4] 1at org.apache.solr.handler.SnapPuller$2.run(SnapPuller.java:666) [junit4:junit4] 1 Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked for write for core collection1 [junit4:junit4] 1at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:484) [junit4:junit4] 1at org.apache.solr.core.SolrCore.init(SolrCore.java:745) [junit4:junit4] 1... 3 more [junit4:junit4] 1 ERROR - 2013-04-14 16:48:20.864; org.apache.solr.handler.SnapPuller$2; Could not reload core [junit4:junit4] 1 org.apache.solr.common.SolrException: Unable to reload core: collection1 [junit4:junit4] 1at org.apache.solr.core.CoreContainer.recordAndThrow(CoreContainer.java:1432) [junit4:junit4] 1at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1118) [junit4:junit4] 1at org.apache.solr.handler.SnapPuller$2.run(SnapPuller.java:666) [junit4:junit4] 1 Caused by: org.apache.solr.common.SolrException: Index locked for write for core collection1 [junit4:junit4] 1at org.apache.solr.core.SolrCore.init(SolrCore.java:821) [junit4:junit4] 1at org.apache.solr.core.SolrCore.reload(SolrCore.java:408) [junit4:junit4] 1at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1108) [junit4:junit4] 1... 1 more [junit4:junit4] 1 Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked for write for core collection1 [junit4:junit4] 1at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:484) [junit4:junit4] 1at org.apache.solr.core.SolrCore.init(SolrCore.java:745) [junit4:junit4] 1... 3 more -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 235 - Failure
: REGRESSION: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication This failure reproduces for me, but only with -Dtests.multiplier=2 -Dtests.nightly=true -- which makes perfect sense since hte test does more stressing when it's a nightly. I believe the problem is purely because of the order of documents in the index, and the fact that no sort is used on the test queries. when i add an explicit sort to the query() method in this test, thta seed starts passing for me. I'm still testing, but assuming i haven't caused any other problems in this class i'll commit as part of SOLR-4629. : Error Message: : expected:null but was:[0][id][0]:860!=0 : : Stack Trace: : java.lang.AssertionError: expected:null but was:[0][id][0]:860!=0 : at __randomizedtesting.SeedInfo.seed([C5C64A35E51A1C6A:1E6D4AF3E03275D9]:0) : at org.junit.Assert.fail(Assert.java:93) : at org.junit.Assert.failNotEquals(Assert.java:647) : at org.junit.Assert.assertEquals(Assert.java:128) : at org.junit.Assert.assertEquals(Assert.java:147) : at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:787) -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4935) CustomScoreQuery has broken boosting
Robert Muir created LUCENE-4935: --- Summary: CustomScoreQuery has broken boosting Key: LUCENE-4935 URL: https://issues.apache.org/jira/browse/LUCENE-4935 Project: Lucene - Core Issue Type: Bug Components: core/query/scoring Reporter: Robert Muir CustomScoreQuery wrongly applies boost^2 instead of boost. It wrongly incorporates its boost into the normalization factor passed down to subquery (like booleanquery does) and *also* multiplies it directly in its scorer. The only reason the test passes today is because it compares raw score magnitudes when querynorm is on, which normalizes this away. Changing the test to use newSearcher() demonstrates the brokenness. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4935) CustomScoreQuery has broken boosting
[ https://issues.apache.org/jira/browse/LUCENE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4935: Attachment: LUCENE-4935.patch CustomScoreQuery has broken boosting Key: LUCENE-4935 URL: https://issues.apache.org/jira/browse/LUCENE-4935 Project: Lucene - Core Issue Type: Bug Components: core/query/scoring Reporter: Robert Muir Attachments: LUCENE-4935.patch CustomScoreQuery wrongly applies boost^2 instead of boost. It wrongly incorporates its boost into the normalization factor passed down to subquery (like booleanquery does) and *also* multiplies it directly in its scorer. The only reason the test passes today is because it compares raw score magnitudes when querynorm is on, which normalizes this away. Changing the test to use newSearcher() demonstrates the brokenness. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4709) dir lock error if reopening cores to fast?
[
https://issues.apache.org/jira/browse/SOLR-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller reassigned SOLR-4709:
-
Assignee: Mark Miller
dir lock error if reopening cores to fast?
--
Key: SOLR-4709
URL: https://issues.apache.org/jira/browse/SOLR-4709
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Mark Miller
While testing my patch for SOLR-4629, i noticed a really random error that i
traced back to the core reload (do to config file replication) failed because
the directory was locked.
From what i can tell, the lock checking code in the SolrCore constructor
isn't even suppose to be used in the reload situation where there is a prev
core, except that in SolrCore.reload there is this check...
{noformat}
if (!getNewIndexDir().equals(getIndexDir())) {
// the directory is changing, don't pass on state
prev = null;
}
{noformat}
..i'm not really sure i understand this logic, or what exactly the source of
the problem is, or if the lock checking code should just be changed to work a
differnet way completley, but it seemed worthy of tracking in it's own jira.
log details to follow
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4709) dir lock error if reopening cores to fast?
[
https://issues.apache.org/jira/browse/SOLR-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-4709:
--
Fix Version/s: 5.0
4.3
dir lock error if reopening cores to fast?
--
Key: SOLR-4709
URL: https://issues.apache.org/jira/browse/SOLR-4709
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Mark Miller
Fix For: 4.3, 5.0
While testing my patch for SOLR-4629, i noticed a really random error that i
traced back to the core reload (do to config file replication) failed because
the directory was locked.
From what i can tell, the lock checking code in the SolrCore constructor
isn't even suppose to be used in the reload situation where there is a prev
core, except that in SolrCore.reload there is this check...
{noformat}
if (!getNewIndexDir().equals(getIndexDir())) {
// the directory is changing, don't pass on state
prev = null;
}
{noformat}
..i'm not really sure i understand this logic, or what exactly the source of
the problem is, or if the lock checking code should just be changed to work a
differnet way completley, but it seemed worthy of tracking in it's own jira.
log details to follow
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4935) CustomScoreQuery has broken boosting
[ https://issues.apache.org/jira/browse/LUCENE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632264#comment-13632264 ] Uwe Schindler commented on LUCENE-4935: --- Oh oh! Thanks for investigating this! Is this new in 4.x? I used CustomScoreQuery in the past in 3.6 and did not recognize that bug. CustomScoreQuery has broken boosting Key: LUCENE-4935 URL: https://issues.apache.org/jira/browse/LUCENE-4935 Project: Lucene - Core Issue Type: Bug Components: core/query/scoring Reporter: Robert Muir Attachments: LUCENE-4935.patch CustomScoreQuery wrongly applies boost^2 instead of boost. It wrongly incorporates its boost into the normalization factor passed down to subquery (like booleanquery does) and *also* multiplies it directly in its scorer. The only reason the test passes today is because it compares raw score magnitudes when querynorm is on, which normalizes this away. Changing the test to use newSearcher() demonstrates the brokenness. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4935) CustomScoreQuery has broken boosting
[
https://issues.apache.org/jira/browse/LUCENE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632273#comment-13632273
]
Robert Muir commented on LUCENE-4935:
-
Uwe: yes the bug is in 3.6 too: see CustomWeight's normalize (boost1)
{code}
@Override
public void normalize(float norm) {
norm *= getBoost(); // incorporate boost
subQueryWeight.normalize(norm);
{code}
and CustomScorer.score (boost2)
{code}
return qWeight * provider.customScore(subQueryScorer.docID(),
subQueryScorer.score(), vScores);
{code}
CustomScoreQuery has broken boosting
Key: LUCENE-4935
URL: https://issues.apache.org/jira/browse/LUCENE-4935
Project: Lucene - Core
Issue Type: Bug
Components: core/query/scoring
Reporter: Robert Muir
Attachments: LUCENE-4935.patch
CustomScoreQuery wrongly applies boost^2 instead of boost.
It wrongly incorporates its boost into the normalization factor passed down
to subquery (like booleanquery does) and *also* multiplies it directly in its
scorer.
The only reason the test passes today is because it compares raw score
magnitudes when querynorm is on, which normalizes this away.
Changing the test to use newSearcher() demonstrates the brokenness.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4935) CustomScoreQuery has broken boosting
[ https://issues.apache.org/jira/browse/LUCENE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4935: Attachment: LUCENE-4935.patch Here is an updated patch thats more correct in my opinion (but the first one fixes the bug). In my opinion this query should not 'distribute' any boosts down to subQuery, because an arbitrary function will be executed on that score that might not adhere to the distributive law. So if someone has a BooleanQuery(CustomScoreQuery(TermQuery)))^5, but their CustomScoreProvider scores with log(subQueryScore) + valSrcScore, they might wonder what happened to their boost of 5 on the outer booleanquery. This is more of a corner case, but i think it simplifies the thing so it acts more like ConstantScoreQuery. CustomScoreQuery has broken boosting Key: LUCENE-4935 URL: https://issues.apache.org/jira/browse/LUCENE-4935 Project: Lucene - Core Issue Type: Bug Components: core/query/scoring Reporter: Robert Muir Attachments: LUCENE-4935.patch, LUCENE-4935.patch CustomScoreQuery wrongly applies boost^2 instead of boost. It wrongly incorporates its boost into the normalization factor passed down to subquery (like booleanquery does) and *also* multiplies it directly in its scorer. The only reason the test passes today is because it compares raw score magnitudes when querynorm is on, which normalizes this away. Changing the test to use newSearcher() demonstrates the brokenness. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4662: - Attachment: SOLR-4662.patch NOTE: This final version of the patch is against 4x. I made a couple of trivial changes that didn't affect the code execution (he says), tested, and committed to trunk without making a final patch. Just so we have a record. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632457#comment-13632457
]
Robert Muir commented on SOLR-3251:
---
Steve asked me for a review, so I took a quick look, just a few things i
noticed (the codec/sim factory is much better without the 2 inform methods,
thanks!):
In CodecFactory:
{code}
public Codec getCodec() {
-assert codec != null : inform must be called first;
{code}
Why remove this assert? I think this is pretty useful otherwise you can get a
difficult-to-diagnose NPE. Same goes with the SimilarityFactory.
In SolrCore:
{code}
if (schema instanceof ManagedIndexSchema schema.isMutable()
resourceLoader instanceof ZkSolrResourceLoader) {
this.zkIndexSchemaReader = new ZkIndexSchemaReader(this);
} else {
this.zkIndexSchemaReader = null;
}
{code}
Why is this in SolrCore? Nothing in SolrCore uses this zkIndexSchemaReader. I
dont think this belongs here: i think it should be in
ManagedIndexSchemaFactory... like it should be core-aware or whatever and do
this itself.
In SolrIndexSearcher.java:
{code}
/** Direct access to the IndexSchema for use with this searcher */
- public IndexSchema getSchema() { return schema; }
+ public IndexSchema getSchema() { return core.getSchema(); }
{code}
I'm confused about this in conjunction with your previous comment:
{quote}
Schema is now effectively immutable: requests see the same schema snapshot for
their lifetimes.
{quote}
Then isn't it dangerous for things to be pulling moving-target schemas off of
SolrCores/SolrIndexSearchers? Shouldn't they be only getting this from the
request? I made this package-private just to see the damage and its not clear
to me that your statement really holds for all this query code :)
In FieldCollectionResource.java:
{code}
ManagedIndexSchema newSchema = ManagedIndexSchema.addFields(getSolrCore(),
newFieldsArray);
getSolrCore().setSchema(newSchema);
{code}
It would be nice if we could at least add a TODO to refactor some of this. I
think its a little confusing that IndexSchema itself has getMutable, but
operations like this go directly to the implementation (abstraction violation).
From a pluggability perspective it would be nice if e.g. addFields was factored
down (e.g. IndexSchema becomes abstract and minimal), and the immutable default
impl threw UOE for changes or whatever... But i know this is a lot of work, it
would be a good followup issue and probably good to do before schema gets any
more hair (there is already tons of backwards cruft thrown about it for compat
etc too).
In ExternalFileField.java:
{code}
/**
* Informs the {@link org.apache.solr.schema.IndexSchema} provided by the
codeschema/code
* parameter of an event (e.g., a new {@link
org.apache.solr.schema.FieldType} was added, etc.
*
* @param schema The {@link org.apache.solr.schema.IndexSchema} instance that
inform of the update to.
* @since SOLR-1131
*/
@Override
public void inform(IndexSchema schema) {
{code}
This should be unnecessary duplication... javadocs by default copies this from
the overridden interface (SchemaAware). So I'd remove it completely, if there
is anything ExternalFileField-specific that needs to be appended to this, then
the base doc can be sucked in with inheritDoc.
(the same goes for several other classes, e.g. i see this in
ExternalFileFieldReloader too).
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Steve Rowe
Fix For: 4.3
Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
SOLR-3251.patch, SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3838) Multiple filter queries are not supported in the Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3838: - Attachment: screenshot-1.jpg Okay... 1. I don't see the - buttons - see the screen shot. I checked the style sheet and the referenced file, url(../../img/ico/minus-button.png ), does not exist. 2. Add fq seems to work fine. 3. When I had 4 fq's (111, 222, 333, 444) and I clicked where the - button should be for the 222 row, it in fact deleted the 222 row, but also deleted the 444 row! Leaving the state shown in the screen shot. 4. If I fill in a new row/fq and hit Enter, everything is fine, but... then there is no - button for that new row. Or maybe that's just because the image file is missing. You can see the actual fq's in the XML query response. This is Google Chrome. Local build of trunk plus the patch. Multiple filter queries are not supported in the Solr Admin Query UI Key: SOLR-3838 URL: https://issues.apache.org/jira/browse/SOLR-3838 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Reporter: Jack Krupansky Attachments: screenshot-1.jpg, SOLR-3838.patch The Solr Admin Query UI has only a single fq input field, which does not permit the user to enter multiple filter query parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632477#comment-13632477 ] Yonik Seeley commented on SOLR-3251: bq. Then isn't it dangerous for things to be pulling moving-target schemas off of SolrCores/SolrIndexSearchers? Shouldn't they be only getting this from the request? On a normal search-side request, yes. Some things may need the latest schema though... like a codec provider, perhaps realtime-get, the future code to add new fields on demand (aka type guessing), etc. bq. it would be nice if e.g. addFields was factored down +1, but not a big deal or a show stopper though. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Assignee: Steve Rowe Fix For: 4.3 Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-4662. -- Resolution: Fixed Trunk r: 1468284 4xr: 1468289 Let's open up new JIRAs for anything that needs to change. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4716) this bug for fixed bug SOLR-4210. proxy request for remote core
Po Rui created SOLR-4716: Summary: this bug for fixed bug SOLR-4210. proxy request for remote core Key: SOLR-4716 URL: https://issues.apache.org/jira/browse/SOLR-4716 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.2 Reporter: Po Rui For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some more web server) cause the IOUtils.closeQuietly(os) wouldn't flush before close the stream in org.apache.catalina.connector.CoyoteOutputStream. this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4716) this bug for fixed bug SOLR-4210. proxy request for remote core
[ https://issues.apache.org/jira/browse/SOLR-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4716: - Description: For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some other web server too) cause the IOUtils.closeQuietly(os) wouldn't flush before close . this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1. so we should invoke flush() explicitly before close. (was: For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some more web server) cause the IOUtils.closeQuietly(os) wouldn't flush before close the stream in org.apache.catalina.connector.CoyoteOutputStream. this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1) this bug for fixed bug SOLR-4210. proxy request for remote core Key: SOLR-4716 URL: https://issues.apache.org/jira/browse/SOLR-4716 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.2 Reporter: Po Rui For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some other web server too) cause the IOUtils.closeQuietly(os) wouldn't flush before close . this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1. so we should invoke flush() explicitly before close. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4716) this bug for fixed bug SOLR-4210. proxy request for remote core
[ https://issues.apache.org/jira/browse/SOLR-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4716: - Attachment: SOLR-4716.patch this bug for fixed bug SOLR-4210. proxy request for remote core Key: SOLR-4716 URL: https://issues.apache.org/jira/browse/SOLR-4716 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.2 Reporter: Po Rui Attachments: SOLR-4716.patch For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some other web server too) cause the IOUtils.closeQuietly(os) wouldn't flush before close . this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1. so we should invoke flush() explicitly before close. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632524#comment-13632524
]
Robert Muir commented on SOLR-3251:
---
{quote}
On a normal search-side request, yes. Some things may need the latest schema
though... like a codec provider, perhaps realtime-get, the future code to add
new fields on demand (aka type guessing), etc.
{quote}
But my problem is with the API: an IndexSearcher is absolutely the worst place
to have a getter for a moving target: because its all about search.
If for example, realtime-get wants to get the 'latest', it should get it from
request.getCore().getCurrentSchema() (please, name it in such a way that its
not confusing).
Otherwise in general things should use request.getSchema(). SolrIndexSearcher
should not expose the schema: there need not be 3 different ways, 2 of which
have current semantics and one of which is immutable across the request. And
its own internal use of moving target should be carefully contained.
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Steve Rowe
Fix For: 4.3
Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
SOLR-3251.patch, SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632529#comment-13632529
]
Mark Miller commented on SOLR-4584:
---
Looks like Po got to the bottom of this in SOLR-4210 - since he has a patch,
I'll make this a duplicate of that and finish up the fix in SOLR-4210.
Request proxy mechanism not work if rows param is equal to zero
---
Key: SOLR-4584
URL: https://issues.apache.org/jira/browse/SOLR-4584
Project: Solr
Issue Type: Bug
Affects Versions: 4.2
Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
Fix For: 4.3, 5.0
Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot
02.png, Screen Shot 03.png, select
If I try to do a request like:
http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
The request fail. The solr UI logging has this error:
{code:java}
null:org.apache.solr.common.SolrException: Error trying to proxy request for
url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
{code}
Chrome says:
This webpage is not available
The webpage at
http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might
be temporarily down or it may have moved permanently to a new web address.
Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
If the param rows is set to rows=4 or superior the query return data as
expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632529#comment-13632529
]
Mark Miller edited comment on SOLR-4584 at 4/16/13 3:21 AM:
Looks like Po got to the bottom of this in SOLR-4716 - since he has a patch,
I'll make this a duplicate of that and finish up the fix in SOLR-4210.
was (Author: markrmil...@gmail.com):
Looks like Po got to the bottom of this in SOLR-4210 - since he has a
patch, I'll make this a duplicate of that and finish up the fix in SOLR-4210.
Request proxy mechanism not work if rows param is equal to zero
---
Key: SOLR-4584
URL: https://issues.apache.org/jira/browse/SOLR-4584
Project: Solr
Issue Type: Bug
Affects Versions: 4.2
Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
Fix For: 4.3, 5.0
Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot
02.png, Screen Shot 03.png, select
If I try to do a request like:
http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
The request fail. The solr UI logging has this error:
{code:java}
null:org.apache.solr.common.SolrException: Error trying to proxy request for
url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
{code}
Chrome says:
This webpage is not available
The webpage at
http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might
be temporarily down or it may have moved permanently to a new web address.
Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
If the param rows is set to rows=4 or superior the query return data as
expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4717) SimpleFacets should respect localParams
Ryan McKinley created SOLR-4717:
---
Summary: SimpleFacets should respect localParams
Key: SOLR-4717
URL: https://issues.apache.org/jira/browse/SOLR-4717
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
In trying to implement http://wiki.apache.org/solr/HierarchicalFaceting I found
the need to send multiple prefix facets in the same request on the same field.
Currently facet params will parse the localParams, but only use them to pick
out a name. We can easily modify things to let localParams override global
ones. For example:
{code}
{!key=level3 facet.prefix=3/path/to/folder}path
{!key=level2 facet.prefix=2/path/to}path
{!key=level1 facet.prefix=1/path}path
{code}
This can easily be supported if we use:
{code:java}
params = SolrParams.wrapDefaults(localParams, orig);
{code}
when local params exist
--
We have come a long way from *simple* facets!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4717) SimpleFacets should respect localParams
[
https://issues.apache.org/jira/browse/SOLR-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-4717:
Attachment: SOLR-4717-FacetLocalParams.patch
The meat of the patch is really just:
{code:java}
+if (localParams == null) {
+ return;
+}
+params = SolrParams.wrapDefaults(localParams, orig);
{code}
SimpleFacets should respect localParams
---
Key: SOLR-4717
URL: https://issues.apache.org/jira/browse/SOLR-4717
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-4717-FacetLocalParams.patch
In trying to implement http://wiki.apache.org/solr/HierarchicalFaceting I
found the need to send multiple prefix facets in the same request on the same
field.
Currently facet params will parse the localParams, but only use them to pick
out a name. We can easily modify things to let localParams override global
ones. For example:
{code}
{!key=level3 facet.prefix=3/path/to/folder}path
{!key=level2 facet.prefix=2/path/to}path
{!key=level1 facet.prefix=1/path}path
{code}
This can easily be supported if we use:
{code:java}
params = SolrParams.wrapDefaults(localParams, orig);
{code}
when local params exist
--
We have come a long way from *simple* facets!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4715) CloudSolrServer does not provide support for setting XmlResponseWriter
[ https://issues.apache.org/jira/browse/SOLR-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632562#comment-13632562 ] Shawn Heisey commented on SOLR-4715: Is there a reason that you can't use javabin? It is more efficient than XML and should work perfectly for any SolrJ code where you are using java objects. There could be an aspect of this that I am not seeing, but CloudSolrServer really has no need for XML responses at this time. It could be argued that allowing for a different response parser is a good idea, so I'll leave this issue open and let someone more experienced decide whether it should be closed or pursued. The only *compelling* reason I know about to use XML responses in SolrJ is when you need to connect to a Solr version running a different version of javabin. The javabin version changed from 1 to 2 when Solr 3.1.0 was released, in order to fix some bugs. I'm not aware of any reason at this time to make javabin version 3. CloudSolrServer only exists in SolrJ 4.0 and later, and can only be used with Solr 4.0 and later, so there are no javabin issues. Due to how fast SolrCloud (and its Zookeeper integration) is changing, I would not recommend using mismatched Solr and SolrJ versions with CloudSolrServer. Although cross-version compatibility is a strong goal with SolrJ, SolrCloud is under pretty heavy development. LBHttpSolrServer is a little different. It's been around forever, so the javabin incompatibility could be a problem. Thankfully, it has a contructor that will let you build it with a different response parser: http://lucene.apache.org/solr/4_2_1/solr-solrj/org/apache/solr/client/solrj/impl/LBHttpSolrServer.html#LBHttpSolrServer%28org.apache.http.client.HttpClient,%20org.apache.solr.client.solrj.ResponseParser,%20java.lang.String...%29 CloudSolrServer does not provide support for setting XmlResponseWriter -- Key: SOLR-4715 URL: https://issues.apache.org/jira/browse/SOLR-4715 Project: Solr Issue Type: Bug Reporter: Hardik Upadhyay Labels: solr, solrj CloudSolrServer as well as LBHttpSolrServer does not allow to set XMLResponseWriter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1488) autoCommit when idle
[ https://issues.apache.org/jira/browse/SOLR-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632587#comment-13632587 ] Shawn Heisey commented on SOLR-1488: My gut instinct on reading this was that allowing this could lead to an alternate way of creating huge tlog problems ... someone might define only idleTime and leave the others out. After a few minutes of thinking about it, it's probably not any worse than the existing ways that people end up with huge tlogs. It seems to me that honoring both idleTime and maxTime would be the best way to go. Using the example, if you have ten seconds of idle time, it should commit. If you have a period of 30 seconds where each idle time never gets to 10 seconds, go ahead and commit. That would be harder to code, but the end result would be better. If this issue does get fixed, when I get around to making a 'huge tlog' wiki page, I can include some advice about using maxDocs and/or maxTime in addition to idleTime. autoCommit when idle Key: SOLR-1488 URL: https://issues.apache.org/jira/browse/SOLR-1488 Project: Solr Issue Type: Improvement Reporter: Matt Weber Priority: Minor Attachments: SOLR-1488.patch Enable autoCommit to execute after a given amount of idle time (no documents submitted). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
