Hello, Can't the ID (uniqueKey) of the indexed documents (i.e. denormalized data) be a combination of the master product id and the child product id ?
Therefor whenever you update your master product db entry, you simply need to reindex documents depending on the master product entry. You can even simply reindex your whole DB, updates are made in place (i.e. old documents are *completely* overwritten by their respective updates). There's nothing to delete if you build your unique key in a "maintainable" way. You can re-index documents whenever you need to do so. -- Tanguy 2012/5/22 Sohail Aboobaker <sabooba...@gmail.com> > Hi, > > I have a very basic question and hopefully there is a simple answer to > this. We are trying to index a simple product catalog which has a master > product and child products. Each master product can have multiple child > products. A master product can be assigned one or more product categories. > Now, we need to be able to show counts of categories based on number of > child products in each category. We have indexed data using a join and > selecting appropriate values for index from each table. This is basically a > De-normalized result set. It works perfectly for our search purposes. > However, maintaining the index and keeping index up to date is an issue. > Whenever a product master is updated with a new category, we will need to > delete all the index entries for child products in index and insert them > again. This seems a lot of activity for a regular on-going operation i.e. > product category updates. > > Since, join between schemas is only available in 4.0, what are other > strategies to maintain or to create such queries. > > Thanks for your help. > > Regards, > Sohail >
