[
https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147215#comment-17147215
]
David Smiley commented on SOLR-14601:
-------------------------------------
> child has only three allowed parameters: parentFilter,childFilter and limit.
Not only those; it clearly supports "fl". It's in the docs and also in the code
snippet you shared.
I think in this case the solution is to be explicit in the "fl" inside child:
{code:java}
fl=*,[child fl=*],customer:[subquery]
{code}
Assuming that works, maybe it wasn't obvious enough and maybe it'd be nice if
Solr could somehow figure out this case automatically. I definitely don't like
the idea of ChildDocTransformer somehow expressly excluding certain other
transformers because it would preclude 3rd party plugins. Instead, I'd prefer
some sort of solution where a TransformerFactory could detect it's being
activated from child's field list and then choose to opt itself out, or instead
declare this preference.
> Using [child] and [subquery] DocTransformer / FieldList
> -------------------------------------------------------
>
> Key: SOLR-14601
> URL: https://issues.apache.org/jira/browse/SOLR-14601
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
> Affects Versions: master (9.0), 8.5.2
> Environment: Docker Container 8.5.2 from Docker Hub
> Already existing in 9.0.0
> Reporter: Thomas Taroni
> Priority: Major
>
> If you are using in the fl parameter something like that and
> luceneMatchVersion is higher or equals then 8.0.0 :
> fl=*,[child],customer:[subquery] or
> fl=*,customer:[subquery],[child]
> It ends Up in any case in the following error (BadRequest) inside the
> SubQueryAugmenterFactory:
> {code:java}
> // code placeholder
> if (conflictMap.containsKey(field)) {
> throw new SolrException(ErrorCode.BAD_REQUEST,"[subquery] name "+field+" is
> uplicated");
> } else {
> conflictMap.put(field, true);
> }
> {code}
> It looks like that the following Snippet in ChildDocTransformerFactory(8.5.2
> and 9.0.0) already have added that field to the context.
> {code:java}
> // code placeholder 8.5.2
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if(childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else if(req.getSchema().getDefaultLuceneMatchVersion().major < 8) {
> // ensure backwards for versions prior to SOLR 8
> childSolrReturnFields = new SolrReturnFields();
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> {code:java}
> // code placeholder master 9.0.0
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if (childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> It looks like childReturnFields includes also the customer:[subquery],
> eventually is a good idea to remove fields from other AugmenterFactories like
> [shard] or [subquery] from the childReturnFields variable
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
