Copied to clipboard

Flag this post as spam?

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


  • robjakedorsett 13 posts 63 karma points
    Jan 13, 2022 @ 14:24
    robjakedorsett
    0

    ExamineX - Price Picker

    Hi Matt, We have moved over to ExamineX due to the known issues with hosting Umbraco on azure.

    Everything seems to be working swimmingly, except this has started appearing: Vendr Price issue

    We typically got this when the internal index was having issues, internal index with ExamineX seems fine, and I have even rebuilt it, with no joy.

    I'm wondering if this is a known issue with ExamineX & Vendr?

    Thanks, Rob

  • Matt Brailsford 3688 posts 19399 karma points MVP 9x c-trib
    Jan 13, 2022 @ 15:01
    Matt Brailsford
    0

    Hi Rob,

    Hmm, no, I've never head of this issue with ExamineX before (but granted, you're the first person I've heard using ExamineX and Vendr together).

    To be honest, I have no idea what ExamineX does / how it affects things but I'd be surprised if it changed the search API.

    Ultimately what Vendr does is use the internal index to search the current pages ancestry to locate to node with a store picker. For some reason it looks like that query is failing. That query is built up using a raw lucene query though so maybe something isn't supported in ExamineX?

    I'm not exactly sure how to resolve this one though, might need a bit of input from Shan on this one. 🤔

  • robjakedorsett 13 posts 63 karma points
    Jan 13, 2022 @ 15:13
    robjakedorsett
    0

    Thanks for the response Matt,

    Yeah it looks like ExamineX auto converts Lucene queries into something Azure Search will understand (https://examinex.online/querying).

    But my guess is you are correct regarding the raw lucene. I guess there must be an issue somewhere.

    Is there any way for us to extend/override the default with this?

  • Matt Brailsford 3688 posts 19399 karma points MVP 9x c-trib
    Jan 13, 2022 @ 15:46
    Matt Brailsford
    0

    Hmm, unfortunately not. It's currently all just hard coded into a helper.

    I have spoken with some other devs about the possibility of creating a "StoreLocator" of sorts which would be responsible for looking up a store from a node ID, but it's only discussions atm. It still needs thoroughly investigating to see what is involved and what changes would be needed.

    Even so, this would ultimately just make it your problem though needing to replace the implementation.

    I could do with knowing if there is a way to make our query compatible, or whether it's down to the fact I'm using a raw query and that just isn't supported?

  • robjakedorsett 13 posts 63 karma points
    Jan 13, 2022 @ 17:37
    robjakedorsett
    0

    Hey Matt, I've raised the question with Shan can be followed here - https://github.com/SDKits/ExamineX/issues/54

    Thanks, Rob

  • Shannon Deminick 1523 posts 5250 karma points MVP
    May 23, 2022 @ 21:04
    Shannon Deminick
    0

    Hi all, I know this has been a while but I'm hoping some additional information can be added to the issue https://github.com/SDKits/ExamineX/issues/54

    Any info like stack traces, what the raw lucene query being executed is, etc...

    Thanks!

  • Matt Brailsford 3688 posts 19399 karma points MVP 9x c-trib
    May 24, 2022 @ 07:30
    Matt Brailsford
    0

    I can't give much about the error as I've not replicated it, but from a Lucene perspective we really aren't doing much in our queries that should be problematic. We basically only run the following query

    (__NodeId:123) (store:[0* TO Z*]) (productSource:[0* TO Z*])
    

    We then process this in memory to locate a relevant store from the results.

    The only other thing we do with examine is manipulate the internal index for querying variants, but this isn't linked to this property editor so can't see that being the issue.

    Just to follow up on my original suggestions, Vendr does now have an IUmbracoNodeStoreFinder to allow folks to locate a store based on a node ID and so if needs be, an ExamineX store finder could be created to replace the Lucene one. But as mentioned above, this just makes it the implementors problem, and really, I can't see anything problematic with the query above that would be over-complex for ExamineX to handle.

Please Sign in or register to post replies

Write your reply to:

Draft