On Mon, Jun 15, 2015 at 10:24 AM, Alessandro Benedetti <benedetti.ale...@gmail.com> wrote: > So why in both cases we express the parent type ? > > ( "Note that regardless > of which direction we are mapping (parents to children or children to > parents) we provide a query that defines the complete set of parents in the > index. In these examples, the parent filter is “type_s:book”. ) > > Is this necessary for implementation reasons ? Is there to prevent to use > other parent -children relations ? Why we don't specify the children type ?
That's just an implementation detail that separates the parents from the children. It's the way the original block join queries worked, so I just kept that part. One could easily pass children and then assume that anything that isn't marked as a child is a parent, but it would be different code to implement that. In the future, we may index more information by default when you index nested child docs that would normally make specifying the parent filter optional. > Example: > *Parent types* : book > *Children types* : user_review, official_review > > Assuming we have in the same index this data. > In two how can we distinguish between the 2 types of children ? Today, it's up to whoever is indexing the nested documents to add type information (like type:book, type:review). There are no requirements on how this is done. In the example above, you could have type:user_review and type:official_review or you could keep the type as "review" and add an additional "isOfficial:true/false" to distinguish. Then if we're mapping from children to parents, it's the responsibility of the base query and filters (or however the facet domain got created) to limit to one child type if they want. For example, a filter might be fq=isOfficial:true of you are only querying official reviews *But* for mapping from parents to children, you've quickly identified a weakness that is on my TODO list ;-) Currently all children (and grandchildren, if multi-leveled) will be selected when using blockChildren. We need a filter (or filters) to apply after the transition to screen out only those children we are interested in *before* we calculate the facets. That would include type info (in the case of multiple child types), but wouldn't be limited to that. -Yonik
