Quick Category Search

blog header image

A request I often get is the ability to search through a lot of pages and list the pages that are in one or more specific categories.

Imagine that you have an article library of say 60.000 articles and your editors have carefully categorized these pages in a large taxonomy defined as EPiServer Categories. Now you want to make a list of all the pages that both belong to the category "Europe" and  the category "Whitepaper".
"No Problem", I hear you cry. "I'll just use FindPagesWithCriteria". Sure! You are right. FindPagesWithCriteria will solve your problem - but with 60.000 articles you'll find that it comes at a high performance cost.

To solve this, I extended the DataAccess layer with the class CategorySearchDB that will go directly against the EPiServer DB with a query that's quite a lot quicker than the one used in FindPagesWithCriteria and return an array of PageReferences.

Just include a reference to the dll and call it like this: EPiServer.Research.DataAccess.CategorySearchDB.FindPages(params int[] Categories) and provide it with the id's of the categories that the pages should be in. Since it returns a list of PageReferences you might also want to call DataFactory.GetPage for each to get a full PageData object - I left it out for performance reasons ( you might not need the PageData object for all the pages you find - just the ones you want to list).

On my local laptop installation with ~10k pages I consequently get response times around 10-20 ms while FindPagesWithCriteria varies from 300ms to 10s.

 

Disclaimer: Kids, don't try this at home! It's really bad practice to interact directly with the EPiServer database. I, however, am not known for following best practices nor do I mind getting my fingers burned (even though I already fear the punishment from the backend dev team).  Finally, in my defence,  this solution does seem to solve the problem at hand. But only expect it to work against EPiServer CMS 5 SP1 and don't come crying if an update makes it stop working. Use at own risk.

Recent posts