I recently noticed an interesting behavior with the navigators in FAST ESP. Just as a refresher, navigators are used in FAST to allow users to quickly filter through results. Navigators facilitate that drill down/up mechanism on a set of search results.
On a project I am currently working on, I have been using FAST navigators so that users can filter the results by books. I created a navigator that contains the values of books and when a query is executed and comes back with results, I manipulated the book navigator so that the user could filter the results by book values (using the navigator modifiers).
Now one thing I noticed when passing in the modifier value (which contains the value of a book) in my code:
.. is that it’s doing some sort of contain logic, meaning that if in your results set, the navigator modifier values starts or ends with the value you are passing in, it will find and give you back a subset of those matching results.
For example, I have two books called “Pédiatrie” and another one called “Maladies génétiques en pédiatrie”. If I let the user click on a filter for the book “Pédiatrie”, the value of the modifier will be set to “Pédiatrie” and subset of the results which will contain items for which the book navigator will match the value “Pédiatrie” should be returned. No! It will also return items for which the book navigator modifier value will match at the beginning and the end the value string “Pédiatrie”. So in our case, results for both “Pédiatrie” and “Maladies génétiques en pédiatrie” are returned, which is not what the user is expecting.
I thought that maybe this could be a bug in the FAST API so I tested the query in the query server to see what kind of results would come back from there if I filter through using the same parameters:
As we can see in the results, two matches (not exact match!) come back:
Obviously, this creates some issues in terms of usability and functionality. Just be aware of the modifier behavior in the API when you design your filters and make sure you pass in a value that is unique enough so that an exact match is always returned. As an alternative solution, you could create an FQL query that targets specifically a field and proceed doing your filtering that way.
I updated FAST ESP to sp3 and this behavior can still be seen.
On a project I am currently working on, I have been using FAST navigators so that users can filter the results by books. I created a navigator that contains the values of books and when a query is executed and comes back with results, I manipulated the book navigator so that the user could filter the results by book values (using the navigator modifiers).
Now one thing I noticed when passing in the modifier value (which contains the value of a book) in my code:
.. is that it’s doing some sort of contain logic, meaning that if in your results set, the navigator modifier values starts or ends with the value you are passing in, it will find and give you back a subset of those matching results.
For example, I have two books called “Pédiatrie” and another one called “Maladies génétiques en pédiatrie”. If I let the user click on a filter for the book “Pédiatrie”, the value of the modifier will be set to “Pédiatrie” and subset of the results which will contain items for which the book navigator will match the value “Pédiatrie” should be returned. No! It will also return items for which the book navigator modifier value will match at the beginning and the end the value string “Pédiatrie”. So in our case, results for both “Pédiatrie” and “Maladies génétiques en pédiatrie” are returned, which is not what the user is expecting.
I thought that maybe this could be a bug in the FAST API so I tested the query in the query server to see what kind of results would come back from there if I filter through using the same parameters:
As we can see in the results, two matches (not exact match!) come back:
Obviously, this creates some issues in terms of usability and functionality. Just be aware of the modifier behavior in the API when you design your filters and make sure you pass in a value that is unique enough so that an exact match is always returned. As an alternative solution, you could create an FQL query that targets specifically a field and proceed doing your filtering that way.
I updated FAST ESP to sp3 and this behavior can still be seen.
We have the same issue and Microsoft helped to solve it. Basically there are 2 parts in the solution. One is in the field definition in the index profile, you need to put in boundary-match attribute, e.g.,
The second part is passing FQL with a begin character “^” and an end character “$”, e.g.,
&navigator=+bootitle:^”pediatrie”$
This tells FAST to match not only the word itself but also the “boundary”.
The last post filter out the angle bracket so here it is:
We have the same issue and Microsoft helped to solve it. Basically there are 2 parts in the solution. One is in the field definition in the index profile, you need to put in boundary-match attribute, e.g.,
< name=”booktitle” lemmatize=”yes” tokenize=”auto” boundary-match=”yes” />
The second part is passing FQL with a begin character “^” and an end character “$”, e.g.,
&navigator=+bootitle:^”pediatrie”$
This tells FAST to match not only the word itself but also the “boundary”.