Catalog gadget custom query for finding products

Vote:
 

Is there a way of implementing search directly against the DB? 

In a similar way that products get shown by clicking on catalog nodes but filtering on them instead?

#191128
Apr 20, 2018 15:30
Vote:
 

The gadget use the index-based search provider, so no, there is no direct query against DB. The filter entries by keyword might be a nice thing to have but that is not supported out of the box 

#191129
Apr 20, 2018 16:11
Vote:
 

Ok. In our solution we have implemented Find in following manner:

There is a class 

public class FindProduct {}

That wraps 

public class ProductBase : ProductContent

Indexing is done by 

public class SiteReindexer : CommerceReIndexInformation

Hooking up Find in the Mediachase.Search.config was done like described here

Index exists when done through CMS job but still nothing gets listed while typing in the search box. I am guessing that instaed of FindSearchIndexBuilder we might have to use our custom search provider?

Is that correct?




                        
#191138
Apr 20, 2018 17:06
Vote:
 

I didn't quite see it mentioned on the page you linked, but did you change the provider on the front end site as well? There are two Mediachase.Search.config files. One in the CM project and one in the Front End project.

#191533
Apr 25, 2018 9:16
Vote:
 

The only (official) way to get search provider to work with Find is to use FindSearchProvider. and that uses Find as an backend, it does not understand the content types, or the indexer. 

And most importantly the UI does not support passing custom query to the search provider. 

#191535
Apr 25, 2018 9:24
Vote:
 

Oh, sorry. I missed the part that it is POCOs that are being indexed and not the IContent.

Yeah, a custom search provider would be necessary in that case.

Or looking into if it is really necessary to index your own POCOs instead of the IContent.

I'd look into the latter first. :)

#191538
Edited, Apr 25, 2018 9:30
Vote:
 

We ended up having two indexing jobs. One that indexes content done 'out of the box'. This one creates index used by catalog widget. Second one is custom that is responsible for search results. 

Main reason for this is the structure of our catalog. 

#191951
May 03, 2018 10:48
Vote:
 

Do you have two documents in the Find index for each languageversion for each product in that case? (One POCO and one "IContent")

#191952
Edited, May 03, 2018 10:53
Vote:
 

Yes. For now it has to stay that way. My understanding is that there was an issue with Find and include clause that didn't work out nice in our case. 

#191966
May 03, 2018 11:44
Vote:
 

Ok, just as a reference for future visitors to this thread, you'll have to consider the pricing tiers with Episerver Find when doing an approach like this. Doubling the amount of documents in the index for all your products isn't always an option for your customers.

The pricing tiers can be found here: https://www.episerver.com/actions/order-episerver-find/

An alternative if you need to index POCOs for your products but still need the product search (both in CM and in the catalog gadget) is to run a dual index setup. Find for your POCO products and other regular content, for use in the front end. And a complimentary Lucene index for products that the admin side of things uses for product catalog searching.

#192011
Edited, May 03, 2018 14:03
Vote:
 

That is a really valid point. Thanks.

#192012
Edited, May 03, 2018 14:09
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.