[
https://issues.apache.org/jira/browse/SOLR-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590297#comment-16590297
]
David Smiley commented on SOLR-12519:
-------------------------------------
Next time I suggest pushing a new commit to the PR so that it's easy for me to
see what change you did. I used a diff tool on your latest patch file with the
one I uploaded before. BTW your latest patch includes tons of changes unrelated
to this issue.
Thinking out-lout.... I _think_ I like the check for the rootDocId needing to
be in the parents bit filter. Was this an actual problem shown by the test?
Could this happen "normally"? I suspect this could only happen if the user/app
isn't following the rules of nested docs – like they updated a child doc by
itself, or something like that. If I'm right, I think we should throw a helpful
exception in this scenario to alert them they are doing something wrong. Or
perhaps this may happen if you do a query for docs that are not exclusively
root docs, and you use the child transformer. Yeah... but is that actually a
problem? I think we should be able to support that just fine. In this case
you want the child docs below the matching child doc being transformed and not
it's parents. Can we explicitly test/support this? I think we should.
I think we can avoid the addedChildDocs flag by checking if
"pendingParentPathsToChildren" is empty; no? Can you add a test triggering this
scenario? I'm aware the _example_ tests caught it but those are more sanity
checks on our shipped configs and/or SolrJ interaction, and not meant to be the
canonical tests for specific Solr features.
{quote}I am having trouble finding the test seed
{quote}
No prob. I think this is the easiest way: Click the "test results" link in the
table. On the page that shows in Jenkins, the failed tests show at the top as
links. Click the link for the failing test. On the page that shows, you'll see
a stack trace. The stack trace will nearly always contain the seed near the top
like so:
{{__randomizedtesting.SeedInfo.seed([BC02A7658A1C547C:CFD8B8FF0604237A]:0)}}
> Support Deeply Nested Docs In Child Documents Transformer
> ---------------------------------------------------------
>
> Key: SOLR-12519
> URL: https://issues.apache.org/jira/browse/SOLR-12519
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: mosh
> Priority: Major
> Attachments: SOLR-12519-fix-solrj-tests.patch,
> SOLR-12519-no-commit.patch, SOLR-12519.patch
>
> Time Spent: 23h 10m
> Remaining Estimate: 0h
>
> As discussed in SOLR-12298, to make use of the meta-data fields in
> SOLR-12441, there needs to be a smarter child document transformer, which
> provides the ability to rebuild the original nested documents' structure.
> In addition, I also propose the transformer will also have the ability to
> bring only some of the original hierarchy, to prevent unnecessary block join
> queries. e.g.
> {code} {"a": "b", "c": [ {"e": "f"}, {"e": "g"} , {"h": "i"} ]} {code}
> Incase my query is for all the children of "a:b", which contain the key "e"
> in them, the query will be broken in to two parts:
> 1. The parent query "a:b"
> 2. The child query "e:*".
> If the only children flag is on, the transformer will return the following
> documents:
> {code}[ {"e": "f"}, {"e": "g"} ]{code}
> In case the flag was not turned on(perhaps the default state), the whole
> document hierarchy will be returned, containing only the matching children:
> {code}{"a": "b", "c": [ {"e": "f"}, {"e": "g"} ]{code}
--
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
