I’ll be honest I didn’t understand most of what you wrote (like I said we’re just getting started with this).  We will most certainly need to do faceted search in future iterations so thanks for the “json.facets” reference.  And I do understand that the ChildDocTransformer is really for controlling what gets output and not for finding or filtering rows.

Your answer started me thinking about solving different parts of the problem in different parts of the query.  I got something that works now:
       q=title:"Under Armour" OR description:"Under Armour"
  fq={!parent which=docType:Product}color:*Blue*
       fl=title, description, brand,id,[child parentFilter="docType:Product" childFilter="color:*Blue*"]  
This does show me only Under Armor products with blue items, and returns just the blue items nested inside the products.  That will work. There may be a more efficient/direct way of doing it, but at least we can move forward.  Is this a good approach?

With respect to multiple levels, it’s not a matter of trying to query more than two nested documents deep, it’s a matter of I haven’t seen a single example of how to query more than two levels.  The documentation and every example I found for ChildDocTransformer and Block Join just show parents and children.  A few hours ago Mikhail graciously send me a link off-list to an article that basically says grandchildren are children too so you can search/filter on them as if they were children, and I understood most of it. Will have to dig into it more.


On 3/20/17, 1:20 PM, "Alexandre Rafalovitch" <[EMAIL PROTECTED]> wrote:

    You should be able to nest things multiple levels deep. What happens
    when you try?
    For trying to find parents where children satisfy some criteria,
    [child] result transformer is probably a bit later. You may want to
    look into json.facets instead and search against children with
    shifting domain up to parents after. Then, you also do the [child]
    transformer to get the expanded children (if you need them).
    http://www.solr-start.com/ - Resources for Solr users, new and experienced
    On 20 March 2017 at 11:58, David Kramer <[EMAIL PROTECTED]> wrote:
    > Hi.  We’re just ramping up a product search engine for our eCommerce site, so this is all new development and we are slowly building up our Solr knowledgebase, so thanks in advance for any guidance.
    > Our catalog (mostly shoes and apparel) has three objects nested: Products (title, description, etc), items (color, price, etc), and SKU (size, etc).  Since Solr doesn’t do documents nested three deep, the SKUs and items both get retrieved as children of products.  That has not bit us yet…  Also, our search results page expects a list of Item objects, then groups them (rolls them up) by their parent object.  Right now we are returning just the items, and that’s great, but we want to implement pagination of the products, so we need to return the items nested in products, then paginate on the products.
    > If I send ‘q=docType:Product description:Armour&fl=title, description,id,[child parentFilter="docType:Product" childFilter="docType:Item"]’ I get a nice list of products with items nested inside them. Woot.
    > The problem is, if we want to filter on item attributes, I get back products that have no children, which means we can’t paginate on the results if we remove those parents.  For instance, send ‘q=docType:Product description:Armour&fl=title, description,id,[child parentFilter="docType:Product" childFilter="docType:Item AND price:49.99"]’, we get the products and their items nicely nested, and only items with a price of 49.99 are shown, but so are parents that have no matching items.
    > How can I build a query that will not return parents without children? I haven’t figured out a way to reference the children in the query.
    > Since we’re not in production yet, I can change lots of things here.  I would PREFER not to denormalize the documents into one document per SKU with all the item and product information too, as our catalog is quite large and that would lead to a huge import file and lots of duplicated content between documents in the index.  If that’s the only way, though, it is possible.
    > Thanks in advance.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB