Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Rahul Sekhar 9 posts 85 karma points
    Feb 26, 2017 @ 07:55
    Rahul Sekhar
    0

    Alternatives to lookups in Examine events

    I'm building a site that has fairly tightly related nodes. The page for a project might reference articles. These references are made using multinode treepickers and relations.

    When I search for, say, an article, I want related projects to appear in my results as well. To have this happen, I was planning to hook into Examine events, query related nodes and add their title to the index.

    The Umbraco common pitfalls document says to avoid service lookups in these events (https://our.umbraco.org/documentation/reference/Common-Pitfalls/#performing-lookups-and-logic-in-examine-events). Can I solve this problem without making lookups? I imagine this is a common use case.

  • Micha Somers 134 posts 597 karma points
    Feb 26, 2017 @ 11:28
    Micha Somers
    0

    Using Examine this way would indeed lead to poor performance for indexing.

    In situations with lot's of nodes and where lookup's are needed, using XPath could provide a better performance. UmbracoHelper has several XPath functions like ContentAtXPath (see https://our.umbraco.org/documentation/reference/querying/umbracohelper/) that help to find the right content efficiently.

    Somewhat outdated (concerning uQuery) but still useful conversations related to this topic can be found in: https://our.umbraco.org/forum/developers/api-questions/45777-uQuery-vs-Examine-vs-IPublishedContent-for-Querying

  • Rahul Sekhar 9 posts 85 karma points
    Mar 05, 2017 @ 12:36
    Rahul Sekhar
    0

    I already have a set of models based on IPublishedContent data. I didn't want to have a duplicate set that operate on XPath.

    What I've done is to hook into the Published event of any searchable document and store searchable fields (which are put together in the model itself) in a set of internal fields on the document. These are then indexed as usual.

    This way there's no performance hit for indexing, only a slight hit while publishing which isn't a big concern.

Please Sign in or register to post replies

Write your reply to:

Draft