Jim, I think you hit the nail on the head... that's not what BlockJoinQueries do.
If you're wanting to search for children and join to their parents... then use ToParentBlockJoinQuery, with a query that matches the set of children and a filter that matches the set of parents. If you're searching for parents, then joining to their children... then use ToChildBlockJoinQuery, with a query that matches the set of parents and a filter that matches the set of children. When you add related documents to the index (via addDocuments), make that children are added before their parents. The reason all the above is necessary is that it makes it possible to have a nested hierarchy of relationships (ie. Parents have Children, which have Children of their own). You need a query to indicate which part of the hierarchy you're starting from, and a filter indicating which part of the hierarchy you're joining to. Also, you will always get an exception if your query and your filter both match the same document. A child can't be its own parent. BlockJoin is a very powerful feature, but what it's really doing is modelling relationships using an index that doesn't know what a relationship is. The relationships are determined by a combination of the order that you indexed the block, and the format of your query. This disjoin can lead to some weird behavior if you're not absolutely sure how it works. Thanks, Greg On Wed, Jan 21, 2015 at 4:34 PM, McKinley, James T < james.mckin...@cengage.com> wrote: > > Am I understanding how this is supposed to work? What I think I am (and > should be) doing is providing a query and filter that specifies the parent > docs and the ToChildBlockJoinQuery should return me all the child docs for > the resulting parent docs. Is this correct? The reason I think I'm not > understanding is that I don't see why I need both a filter and a query to > specify the parent docs when a single query or filter should suffice. Am I > misunderstanding what parentQuery and parentFilter mean, they both refer to > parent docs right? > > Jim >
