[jira] Updated: (SOLR-1803) ExtractingRequestHandler does not propagate multiple values to a multi-valued field
[ https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lance Norskog updated SOLR-1803: Attachment: display-extracting-bug.patch This patch illustrates the problem. Line 90 should succeed but does not. > ExtractingRequestHandler does not propagate multiple values to a multi-valued > field > --- > > Key: SOLR-1803 > URL: https://issues.apache.org/jira/browse/SOLR-1803 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Reporter: Lance Norskog >Priority: Minor > Attachments: display-extracting-bug.patch > > > When multiple values for one field are extracted from a document, only the > last value is stored in the document. If one or more values are given as > parameters, those values are all stored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1803) ExtractingRequestHandler does not propagate multiple values to a multi-valued field
[ https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840472#action_12840472 ] Lance Norskog commented on SOLR-1803: - The attached patch does not fix the bug. It causes the ExtractingRequestHandler test program to illustrated the bug. Line 90 in TestExtractingRequestHandler.java should succeed and does not. [SOLR-1633|http://issues.apache.org/jira/browse/SOLR-1633] comments on a related behavior. This test patch also checks for that behavior. Since both this and 1633 are in the same area, work should be combined. > ExtractingRequestHandler does not propagate multiple values to a multi-valued > field > --- > > Key: SOLR-1803 > URL: https://issues.apache.org/jira/browse/SOLR-1803 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Reporter: Lance Norskog >Priority: Minor > > When multiple values for one field are extracted from a document, only the > last value is stored in the document. If one or more values are given as > parameters, those values are all stored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1803) ExtractingRequestHandler does not propagate multiple values to a multi-valued field
ExtractingRequestHandler does not propagate multiple values to a multi-valued field --- Key: SOLR-1803 URL: https://issues.apache.org/jira/browse/SOLR-1803 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Reporter: Lance Norskog Priority: Minor When multiple values for one field are extracted from a document, only the last value is stored in the document. If one or more values are given as parameters, those values are all stored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840470#action_12840470 ] Yao Ge commented on SOLR-236: - I just applied the latest patch to trunk and I don't quite understand how the "numFound" in the response list is computed. With rows=10&collapse.threshold=1, I got numFound=11, with rows=10&collapse.threshold=2, I got numFound=22. I both cases the actual doc in the list is 10. Why is the numFound reported this way? > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller >Assignee: Shalin Shekhar Mangar > Fix For: 1.5 > > Attachments: collapsing-patch-to-1.3.0-dieter.patch, > collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, field-collapse-3.patch, > field-collapse-4-with-solrj.patch, field-collapse-5.patch, > field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, > field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, > field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, > field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, > field-collapse-5.patch, field-collapse-5.patch, > field-collapse-solr-236-2.patch, field-collapse-solr-236.patch, > field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, > field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > quasidistributed.additional.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236.patch, SOLR-236.patch, SOLR-236.patch, SOLR-236.patch, > SOLR-236.patch, SOLR-236.patch, SOLR-236.patch, solr-236.patch, > SOLR-236_collapsing.patch, SOLR-236_collapsing.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1724) Real Basic Core Management with Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated SOLR-1724: --- Attachment: SOLR-1724.patch Fixed the unit tests that were failing due to the switch over to using CoreContainer's initZooKeeper method. ZkNodeCoresManager is instantiated in CoreContainer. There's a beginning of a UI in zkcores.jsp I think we still need a core move test. I'm thinking of adding backing up a core as an action that may be performed in a new cores version file. > Real Basic Core Management with Zookeeper > - > > Key: SOLR-1724 > URL: https://issues.apache.org/jira/browse/SOLR-1724 > Project: Solr > Issue Type: New Feature > Components: multicore >Affects Versions: 1.4 >Reporter: Jason Rutherglen > Fix For: 1.5 > > Attachments: commons-lang-2.4.jar, gson-1.4.jar, > hadoop-0.20.2-dev-core.jar, hadoop-0.20.2-dev-test.jar, SOLR-1724.patch, > SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch, > SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch, > SOLR-1724.patch, SOLR-1724.patch > > > Though we're implementing cloud, I need something real soon I can > play with and deploy. So this'll be a patch that only deploys > new cores, and that's about it. The arch is real simple: > On Zookeeper there'll be a directory that contains files that > represent the state of the cores of a given set of servers which > will look like the following: > /production/cores-1.txt > /production/cores-2.txt > /production/core-host-1-actual.txt (ephemeral node per host) > Where each core-N.txt file contains: > hostname,corename,instanceDir,coredownloadpath > coredownloadpath is a URL such as file://, http://, hftp://, hdfs://, ftp://, > etc > and > core-host-actual.txt contains: > hostname,corename,instanceDir,size > Everytime a new core-N.txt file is added, the listening host > finds it's entry in the list and begins the process of trying to > match the entries. Upon completion, it updates it's > /core-host-1-actual.txt file to it's completed state or logs an error. > When all host actual files are written (without errors), then a > new core-1-actual.txt file is written which can be picked up by > another process that can create a new core proxy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1750) SystemInfoRequestHandler - replacement for stats.jsp and registry.jsp
[
https://issues.apache.org/jira/browse/SOLR-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840208#action_12840208
]
Erik Hatcher commented on SOLR-1750:
Thanks Hoss for committing!
naming: I'm fine with how it is, but fine if the name changes too and +1 to
adding default registration
> SystemInfoRequestHandler - replacement for stats.jsp and registry.jsp
> -
>
> Key: SOLR-1750
> URL: https://issues.apache.org/jira/browse/SOLR-1750
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SystemStatsRequestHandler.java,
> SystemStatsRequestHandler.java, SystemStatsRequestHandler.java
>
>
> stats.jsp is cool and all, but suffers from escaping issues, and also is not
> accessible from SolrJ or other standard Solr APIs.
> Here's a request handler that emits everything stats.jsp does.
> For now, it needs to be registered in solrconfig.xml like this:
> {code}
> class="solr.SystemStatsRequestHandler" />
> {code}
> But will register this in AdminHandlers automatically before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840177#action_12840177 ] Mark Miller commented on SOLR-1743: --- Hoss - I've got to digest and respond to this more fully later, but: Yes, I def agree the best solution is something entirely different. I agree that the current, historical based stuff is just not right for multicore. What I've tried to do is just hack things back closer to what they were, but a real solution would be to start from scratch and handle things better - Sounds like you have an idea for that, and I'll dig into your explanation when I get a chance and perhaps off some feedback. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all >Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, > SOLR-1743.patch, SOLR-1743.patch > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
