[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716061#comment-15716061
]
Christine Poerschke commented on SOLR-6203:
-------------------------------------------
Hi Judith.
bq. ... it's already confusing ... that the master code base has two Sorts
(rb.getSortSpec().getSort() and rb.getGroupingSpec().getGroupSort()) in play at
the same time in a grouped search (to say nothing of the within-group Sort) ...
Yes, that's a very fair point and looking beyond the scope of this bug fix
ticket here it would be good if confusing code can be made less confusing.
bq. ... the one about rb.getSortSpec() in
SearchGroupShardResponseProcessor.java: ...
* Actually it's then not just about SearchGroupShardResponseProcessor (SGSRP)
really but we can question not just why SGSRP uses both
{{rb.getGroupingSpec().getGroupSort\[Spec\]()}} and {{rb.getSortSpec()}} but
why _anything_ uses both {{rb.getGroupingSpec().getGroupSortSpec().get...()}}
and {{rb.getSortSpec().get...()}} - and from a quick look around all the places
concerned have access to {{rb}} and so have the possibility of using either.
* Okay, then the next logical question is "Is there a difference between the
two?" and a very cursory lookaround finds
[QueryComponent.java|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java]
and
{code}
GroupingSpecification groupingSpec = new GroupingSpecification();
rb.setGroupingSpec(groupingSpec);
final SortSpec sortSpec = rb.getSortSpec();
//TODO: move weighting of sort
final SortSpec groupSortSpec = searcher.weightSortSpec(sortSpec,
Sort.RELEVANCE);
...
groupingSpec.setGroupSortSpec(groupSortSpec);
{code}
* So based on that it seems that:
** the "TODO: move weighting of sort" could help get rid of
GroupingSpecification's groupSort\[Spec\]
** since SearchGroupShardResponseProcessor.process uses (as you say) only the
offset and count part of {{ss}} the
{code}
- SortSpec ss = rb.getSortSpec();
- Sort groupSort = rb.getGroupingSpec().getGroupSort();
+ SortSpec groupSortSpec = rb.getGroupingSpec().getGroupSortSpec();
{code}
change you propose should work and be a small step towards making the code less
confusing.
Code reading and 'thinking aloud' done - does that kind of make sense?
PS: I am not suggesting we get rid of GroupingSpecification's groupSort\[Spec\]
here/at this time nor to pursue the "//TODO: move weighting of sort" here/at
this time. But both would be worthwhile and yes here at this time we can stop
using {{rb.getSortSpec()}} in SearchGroupShardResponseProcessor.process as you
suggested.
Have a good weekend!
Christine
> cast exception while searching with sort function and result grouping
> ---------------------------------------------------------------------
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 4.7, 4.8
> Reporter: Nate Dire
> Assignee: Christine Poerschke
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
> <dynamicField name="*" type="text_general" multiValued="true" />
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE&name=test&numShards=2&maxShardsPerNode=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
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
