Broadleaf Commerce Discussion Forums

Hi,
I'm sure there is a good reason to it, but I wonder why you chose to rebuild the whole Compass index periodically (which induces a delay when a new product can't be found if searched) instead of immediately updating the Compass index on each product creation/deletion? Was it in order to avoid concurrency on the search index?
(My app is particularly sensitive to that delay: it's quite a heavy customization where customers can publish and sell their own products. They could find it weird if their newly published product wasn't available for search until 3 o clock next morning...)

SLP

Hello? Someone?

Sorry we haven't gotten back to you on this. I've forwarded your query to the person who worked on that but I haven't heard from him. I'll ping him again today and see what I can find out.

There are two motivating factors behind why it was implemented this way.

The first is that we didn't want to couple the search index too closely with the Admin portion of the framework. Many clients that we have talked to already have a facility in place to insert data into their database so we needed a way to index that is independent of the Admin portion of the framework. In retrospect, Aspects would help with this issue.

The second motivating factor was to support clustering in the framework. We do support clustered environments. In our design each clustered server has it's own search index. To support what you suggest we would have to send a message to each server telling it to re-index. This could be implemented with the current framework, we simply haven't yet. It is definitely something we will look at.

We also welcome any contributions you may have in this matter.