[jira] [Commented] (SOLR-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14959328#comment-14959328 ] Zaid Ibrahim commented on SOLR-4310: Any updates on this? I'm interested in seeing if this can/will get out, but it looks like this jira has been inactive for over a year. :/ > If groups.ngroups is specified, the docList's numFound should be the number > of groups > - > > Key: SOLR-4310 > URL: https://issues.apache.org/jira/browse/SOLR-4310 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 4.1 >Reporter: Amit Nithian >Assignee: Hoss Man >Priority: Minor > Fix For: 4.9, Trunk > > Attachments: SOLR-4310.patch, SOLR-4310_2.patch, SOLR-4310_3.patch, > SOLR-4310_4.patch > > > If you group by a field, the response may look like this: > > > 138 > 1 > > > 267038365 > > Larry's Grand Ole Garage Country Dance - Pure Country > > > > > > and if you specify group.main then the doclist becomes the result and you > lose all context of the number of groups. If you want to keep your response > format backwards compatible with clients (i.e. clients who don't know about > the grouped format), setting group.main=true solves this BUT the numFound is > the number of raw matches instead of the number of groups. This may have > downstream consequences. > I'd like to propose that if the user specifies ngroups=true then when > creating the returning DocSlice, set the numFound to be the number of groups > instead of the number of raw matches to keep the response consistent with > what the user would expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14959370#comment-14959370 ] Amit Nithian commented on SOLR-4310: I'd welcome anyone who can take my patch and apply it to the latest Solr. Unfortunately I have been out of the Solr "community" for several years so I don't know what has changed or if this is even still a valid patch given how long it's been. Thank for pinging the JIRA and I hope that you can take this and run with it. > If groups.ngroups is specified, the docList's numFound should be the number > of groups > - > > Key: SOLR-4310 > URL: https://issues.apache.org/jira/browse/SOLR-4310 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 4.1 >Reporter: Amit Nithian >Assignee: Hoss Man >Priority: Minor > Fix For: 4.9, Trunk > > Attachments: SOLR-4310.patch, SOLR-4310_2.patch, SOLR-4310_3.patch, > SOLR-4310_4.patch > > > If you group by a field, the response may look like this: > > > 138 > 1 > > > 267038365 > > Larry's Grand Ole Garage Country Dance - Pure Country > > > > > > and if you specify group.main then the doclist becomes the result and you > lose all context of the number of groups. If you want to keep your response > format backwards compatible with clients (i.e. clients who don't know about > the grouped format), setting group.main=true solves this BUT the numFound is > the number of raw matches instead of the number of groups. This may have > downstream consequences. > I'd like to propose that if the user specifies ngroups=true then when > creating the returning DocSlice, set the numFound to be the number of groups > instead of the number of raw matches to keep the response consistent with > what the user would expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13709520#comment-13709520 ] Amit Nithian commented on SOLR-4310: While it's been a few months since I looked at this patch (and unfortunately I don't work with Solr much anymore), I think the patch should be good to go insofar as the unit tests I submitted passes. Is there anything I can do to help get this moving along? If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.4 Attachments: SOLR-4310_2.patch, SOLR-4310_3.patch, SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13709852#comment-13709852 ] Hoss Man commented on SOLR-4310: Amit: when you posted your last patch, you said... bq. Admittedly there are some points I still need to investigate like why the groupcount isn't set in the TopGroups during distributed search. ...is that a non-issue? is there still something there that needs fixed? If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.4 Attachments: SOLR-4310_2.patch, SOLR-4310_3.patch, SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13710047#comment-13710047 ] Amit Nithian commented on SOLR-4310: I apologize for my lack of memory on this... if I recall I don't think it was anything serious and perhaps something that seemed intuitive but wasn't and I had to work around it. If your tests show that this works in distributed mode then it's probably good to go! If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.4 Attachments: SOLR-4310_2.patch, SOLR-4310_3.patch, SOLR-4310_4.patch, SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702504#comment-13702504 ] John Wooden commented on SOLR-4310: --- Amit: Could you elaborate on the remaining issues with distributed search? If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.4 Attachments: SOLR-4310_2.patch, SOLR-4310_3.patch, SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13589865#comment-13589865 ] Hoss Man commented on SOLR-4310: Amit: distributed coordination code never uses DocLists and DocSlices directly (because those are tied to the local index) so you should check the grouping code for SolrDocumentList objects -- in particular look for usages of SolrDocumentList.setNumFound and SolrDocumentList.getNumFound If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.2 Attachments: SOLR-4310_2.patch, SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13589876#comment-13589876 ] Hoss Man commented on SOLR-4310: If i had to guess, i suspect what you want to change is org.apache.solr.search.grouping.endresulttransformer.MainEndResultTransformer .. but there is also org.apache.solr.search.grouping.endresulttransformer.SimpleEndResultTransformer, and i don't know enough about how grouping works to understand the distinction (should one of these be subclassing the other?) Once you track down which of these need changed -- or if both need changed -- it would be best to have either a test of each distributed code path changed, or a defensive test showing that code path which shouldn't be affected by this change is in fact not affected. If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.2 Attachments: SOLR-4310_2.patch, SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590108#comment-13590108 ] Amit Nithian commented on SOLR-4310: Thanks! I'll take a look through this.. I will add some tests to see if I can test for this. Right now I know that the test I added breaks with my patch and passes if I remove the patch. Hitting the debugger I can see why but just trying to make sure I understand the paths before changing something. If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.2 Attachments: SOLR-4310_2.patch, SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587343#comment-13587343 ] Amit Nithian commented on SOLR-4310: Sure let me work on that and resubmit! Thanks If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.2 Attachments: SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13555349#comment-13555349 ] Tomás Fernández Löbbe commented on SOLR-4310: - +1 on the idea. I always thought this is how it should work in this case. If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Priority: Minor Fix For: 4.1 Attachments: SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- 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
