[
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16875173#comment-16875173
]
Christine Poerschke edited comment on SOLR-13585 at 6/28/19 7:41 PM:
---------------------------------------------------------------------
In the context of SOLR-11831 (and assuming separate subsequent small
private-to-protected and Array-or-List-to-Object style tweaks) the factored out
methods would also help avoid code duplication:
* [https://github.com/apache/lucene-solr/pull/300/files#r275043339]
*
[https://github.com/cpoerschke/lucene-solr/commit/10fbfd1dcf16065688c3610b26a55f2aa9c99f8a]
*
[https://github.com/apache/lucene-solr/commit/9480482166b05d04eb2bb55227baf4f3c6549ab9]
* [https://github.com/apache/lucene-solr/pull/300/files#r288569478]
*
[https://github.com/apache/lucene-solr/commit/0eb206bf6f635ba2e7514efa369e09137911b825]
* [https://github.com/apache/lucene-solr/pull/300/files#r298725095]
At this point it might be helpful to briefly outline the difference between the
existing {{SearchGroupsResultTransformer}} and SOLR-11831's proposed and
tentatively named {{SkipSecondStepSearchResultResultTransformer}} class i.e.
what is different between them but why can they still share code:
* The {{SearchGroupsResultTransformer}} transforms search groups i.e. it needs
to know the identity of the group and a sort value for it so that groups from
multiple shards can be collated correctly. In this first phase there is no need
to know the identity of documents in each group since those are determined in
the second phase.
* The {{SkipSecondStepSearchResultResultTransformer}} needs to know everything
that the {{SearchGroupsResultTransformer}} needs to know but if the second
phase is to be skipped (in certain circumstances) then in the first phase there
is a need to know the identity of documents in each group (technically just one
document per group i.e. SOLR-11831 requires group.limit=1).
* In terms of serialisation and deserialisation of search groups therefore the
{{SkipSecondStepSearchResultResultTransformer}} can use the same code as the
{{SearchGroupsResultTransformer}} but there is some extra "add-on" info i.e.
the document identity info that needs to be packed (serialised) and unpacked
(deserialised).
was (Author: cpoerschke):
In the context of SOLR-11831 (and assuming separate subsequent small
{{private}}-->{{protected}} and {{...}}-->{{Object}} tweaks) the factored out
methods would also help avoid code duplication:
* [https://github.com/apache/lucene-solr/pull/300/files#r275043339]
*
[https://github.com/cpoerschke/lucene-solr/commit/10fbfd1dcf16065688c3610b26a55f2aa9c99f8a]
*
[https://github.com/apache/lucene-solr/commit/9480482166b05d04eb2bb55227baf4f3c6549ab9]
* [https://github.com/apache/lucene-solr/pull/300/files#r288569478]
*
[https://github.com/apache/lucene-solr/commit/0eb206bf6f635ba2e7514efa369e09137911b825]
* (add-one-more-link-here-shortly)
At this point it might be helpful to briefly outline the difference between the
existing {{SearchGroupsResultTransformer}} and SOLR-11831's proposed and
tentatively named {{SkipSecondStepSearchResultResultTransformer}} class i.e.
what is different between them but why can they still share code:
* The {{SearchGroupsResultTransformer}} transforms search groups i.e. it needs
to know the identity of the group and a sort value for it so that groups from
multiple shards can be collated correctly. In this first phase there is no need
to know the identity of documents in each group since those are determined in
the second phase.
* The {{SkipSecondStepSearchResultResultTransformer}} needs to know everything
that the {{SearchGroupsResultTransformer}} needs to know but if the second
phase is to be skipped (in certain circumstances) then in the first phase there
is a need to know the identity of documents in each group (technically just one
document per group i.e. SOLR-11831 requires group.limit=1).
* In terms of serialisation and deserialisation of search groups therefore the
{{SkipSecondStepSearchResultResultTransformer}} can use the same code as the
{{SearchGroupsResultTransformer}} but there is some extra "add-on" info i.e.
the document identity info that needs to be packed (serialised) and unpacked
(deserialised).
> factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
> ----------------------------------------------------------------------------
>
> Key: SOLR-13585
> URL: https://issues.apache.org/jira/browse/SOLR-13585
> Project: Solr
> Issue Type: Task
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
> Attachments: SOLR-13585.patch
>
>
> The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
> [#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127]
> and {{transformToNative}} e.g.
> [#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108]
> do quite a few things and factoring out of portions of the code e.g.
> [#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120]
> and
> [#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99]
> could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
