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. 🤔
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?
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.
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:
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
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. 🤔
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?
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?
Hey Matt, I've raised the question with Shan can be followed here - https://github.com/SDKits/ExamineX/issues/54
Thanks, Rob
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!
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
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
IUmbracoNodeStoreFinderto 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.is working on a reply...