Filter Content Area Items

Farhin

Vote:

Hi,
I have a list of ContentArea items on a particular block.
The structure of the block is as follows:
Contact Block

Contact Item Block 1
Contact Item Block 2

This main Contact block is added on a page.The approx. contact items in a single contact block is around 900+.
I need to get the contact items on my UI but before I get it,I need to include some filters to it so that the final content area items are based on the filter & not all of the 900+ items.

I have added the below query which works fine but the problem here is, it gets all the Contact Items first & then apply filters which is why it takes a lot of time more like in minutes.

var contactItems = currentBlock.ContactItemContentArea.FilteredItems
                            .Select(contentItem => _contentRepository.Get<ContactItemBlock>(contentItem.ContentLink))
                            .Where(item => item.Area == "Management" && item.Department == "Finance" && item.Location == "US");

Is there a more efficient way to filter these contentarea items ?

Regards.

#263737

Sep 24, 2021 15:38

Scott Reed

Vote:

If you're using Search & Navigation you could instead just query using Search<ContactItemBlock> blocks that have a) are matching in the ContentLinks from the FilteredItems and b) by your 3 Area types. This will return them via the search service instead of loading them via the database so should be a lot faster. Then it's up to you if you can just use the data loaded directly from S&N or reload them via the IContentLoader

#263889

Edited, Sep 26, 2021 17:47

Farhin - Sep 27, 2021 7:04

Thanks scott for the response.I will give it a try to the approach you suggested but is there an alternative to achieve this without using the search service?

Scott Reed - Sep 27, 2021 8:30

Not sure, it's not wise to do a direct database query and https://world.optimizely.com/documentation/developer-guides/CMS/search/Searching-for-pages-based-on-page-type/ I think only works with page types.

The only other thing coming to mind is storing a keyvalue collection on your block of block IDs and types that are updated on each publish of content via the IContentEvents

Mark Stott - Oct 01, 2021 8:02

I'd agree with Scott in respect of this. Search & Navigation is going to be a much faster solution and is case insensitive by default and only your filtered items will be retrieved from the database when calling GetContentResult(). The current architecture you have requires the loading of 901 items (parent block and 900+ child blocks) which is very inefficient and will also be performing Case Sensitive comparisons.

I would advise against directly querying the database as this requires internal operational knowledge and your query may break during application upgrades.

Dejan Caric

Vote:

Having 900+ blocks on a single page is a lot.

Have you considered changing the architecture and storing contacts in a custom database table(s), for example?

Another option would be to use pages instead of blocks.

You can group them by Location, Department, and Area instead of having 900+ pages under the same node.

If Search is not an option, you might consider using Content Output and/or object caching.

Hope this helps!

#263926

Sep 27, 2021 9:46

Scott Reed - Sep 27, 2021 9:48

I missed the 900+ blocks when I read this. I'd agree with you here, that's a LOT of blocks and way more than I'd ever use.

Mark Stott - Oct 01, 2021 8:04

Optimizely recommend limiting child items to a maximum of 100 for performance reasons. Though this is typically in relation to the site tree.

Farhin - Oct 11, 2021 13:33

Thank you all for your inputs on this.
As suggested ,i have changed the approach to handle this.Rather than going with 900 blocks at the same instance,I have broken down the architecture in a nested hierarchical structure with a combination of filters based on the nested hierarchy to get the results rather than in one go.

Try our conversational search powered by Generative AI!

Filter Content Area Items