[jira] [Commented] (SOLR-14601) Using [child] and [subquery] DocTransformer / FieldList
[ https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147415#comment-17147415 ] Thomas Taroni commented on SOLR-14601: -- *,[child fl='*'],customer:[subquery] -> Has worked as you described expected. After a few more checks i could say the following: if [child] will be react and processed in the same way as [child fl=*] that is a possible expected behavior. currently it heavy to predict what exactly it has for side effects if [child] is picking up every field from fl=. I am absolutely also at the case that is it a bad idea to exclude something here from ChildDocTransformer. On the other side it looks like the duplicate check in SubQueryAugmenterFactory could also be improved. Is a [subquery] is already processed by [child] it should be not processed a second time in fl=. Will check that firstly a little bit deeper. Thanks for answering. > 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
[jira] [Commented] (SOLR-14601) Using [child] and [subquery] DocTransformer / FieldList
[ 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
[jira] [Commented] (SOLR-14601) Using [child] and [subquery] DocTransformer / FieldList
[ https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147117#comment-17147117 ] Mikhail Khludnev commented on SOLR-14601: - {quote}child has only three allowed parameters: parentFilter,childFilter and limit. {quote} I've checked [https://lucene.apache.org/solr/guide/8_5/transforming-result-documents.html#child-childdoctransformerfactory] it says that there's fl in child. Has it been changed since it was documented? [~dsmiley], wdyt? > 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
[jira] [Commented] (SOLR-14601) Using [child] and [subquery] DocTransformer / FieldList
[ https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147101#comment-17147101 ] Thomas Taroni commented on SOLR-14601: -- Have checked that, it looks not that this is working. child has only three allowed parameters: parentFilter,childFilter and limit. Have now investigated the Problem a bit more deeper. It's some kind of recursion. In ChildDocTransformerFactory the variable childReturnFields also includes the other augmenter queries like customer:[subquery] because it picks the full "fl" parameter. It calls then the SolrReturnFields with that. Inside the SolrReturnFields its adding all the Augementers in a for loop for all the fiels. It means if [child] is processed the customer:[subquery] is also processed. If then the customer:[subquery] will be processed by the SubQueryAugmenterFactory the field customer:[subquery] is already there. This ends up then in the "is duplicate" Exception. In my Opinion the ChildDocTransformerFactory should not process things like [subquery] or [shard] or the SubQueryAugmenterFactory should not check that for duplicates. I dont really now the exactly reason why in ChildDocTransformerFactory the full "fl" is processed and not only the "[child]" fields. Have simpli forked the Project to: [https://github.com/phoenix-systems/lucene-solr] and done a short hack, that solves for us the Problem. Commit: [https://github.com/phoenix-systems/lucene-solr/commit/5ce0461ae5da6cf226f435d7e8837132fb045c9d] But i think the better Solution is to change the ChildDocTransformerFactory. > 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
[jira] [Commented] (SOLR-14601) Using [child] and [subquery] DocTransformer / FieldList
[ https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147076#comment-17147076 ] Mikhail Khludnev commented on SOLR-14601: - Hi, [~Thomas Taroni], is it possible to specify {{fl}} inside of {{[child fl...}}] ? > 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