We have a use-case where we are storing all products data and each product can be present in 300 stores and has store specific data like price, offers, etc.
Below is one such example document:
Catalog data Doc:
{
"sku_id":"1231",
"display_name":"spinach",
"size":"250g",
.....
.....
... more other 15-20 fields
}
Store data doc:
{
"store_id":"1",
"sku_id": "1231",
"price":2,
..... another 5-6 fields
}
We modeled these docs as the parent-child relationship in Solr. Where catalog data will be our parent and 300 store specific data will be our child.
We would be performing range filter queries in store price field and this same field would be used for faceting/sorting too. There will not be any search on store (child) docs.
Recently, we have been told that child documents are an anti-pattern(without any reasoning behind it :) ).
If we flatten our documents, the problem is, we would end up creating many dynamic fields in the parent (catalog) document.
We know one limitation, in-place updates in the parent-child relationship, updating one field in a child need replace of the complete block. We have already written a plugin that takes care of doing this inside Solr.
I would like to know the pros and cons of having child-documents in solr vs using dynamic fields
