Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/416#discussion_r213001520
--- Diff:
solr/core/src/test/org/apache/solr/response/transform/TestChildDocTransformerHierarchy.java
---
@@ -238,6 +238,17 @@ public void testSingularChildFilterJSON() throws
Exception {
tests);
}
+ @Test
+ public void testNonRootChildren() throws Exception {
+ indexSampleData(numberOfDocsPerNestedTest);
+ assertJQ(req("q", "test_s:testing",
+ "sort", "id asc",
+ "fl", "*,[child
childFilter='lonely/lonelyGrandChild/test2_s:secondTest'
parentFilter='_nest_path_:\"lonely/\"']",
--- End diff --
Aha; I see you're requiring that a custom parentFilter be present in order
to use the childDocFilter on non-root docs. I suppose that's fine; it
something that could be enhanced in the future to avoid that inconvenience &
limitation(*). Since this is now required, the transformer should throw an
error to the user if the doc to be transformed isn't in that filter. For
example: "The document to be transformed must be matched by the parentFilter
of the child transformer" with BAD_REQUEST flag as it's user-error. And add a
test for this.
(*) An example of it being a limitation is this: Say the child docs are
all a "comment" in nature; and thus are recursive. The top query "q" might
match certain comments of interest. And we want all children of those comments
returned hierarchically. The parentFilter would end up having to match all
comments, but that would prevent returning child comments and thus blocking the
whole idea altogether :-(
To "fix" this limitation, we'd not constrain transformed docs to those in
the parentFilter, and we wouldn't insist on any special parentFilter. In the
loop that builds the hierarchy, when fetching the path, we'd need to skip over
the current doc if it doesn't descend from that of the doc to be transformed.
Seems pretty straight-forward.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
