Tom
My feedback
24 results found
-
3 votesTom
supported this idea
·
-
12 votesTom
supported this idea
·
-
90 votesTom
supported this idea
·
-
4 votes
An error occurred while saving the comment -
7 votesTom
supported this idea
·
-
13 votesTom
shared this idea
·
-
2 votesTom
supported this idea
·
-
30 votesTom
supported this idea
·
-
10 votes
An error occurred while saving the comment Tom
commented
I miss this feature a lot too. It is currently quite difficult to offer multi-selects with OR logic.
Tom
supported this idea
·
-
3 votesTom
supported this idea
·
-
14 votesTom
supported this idea
·
-
2 votesTom
supported this idea
·
-
5 votesTom
supported this idea
·
An error occurred while saving the comment Tom
commented
I like this idea, because it would also allow us not to have to add the entire collection to the search index, but only documents that meet a certain condition.
Typical scenarios would be, for example, archive products that are still in the collection but do not necessarily have to be in the search index. This would reduce the search index.
-
1 vote
An error occurred while saving the comment Tom
commented
Hey Benjamin,
i don't quite understand how this limitation is supposed to make the experience more consistent, because knn is thus completely different from the other operators.Perhaps my expectations for the knn operator are also wrong, but I had thought that one could use this among other things as a replacement / improvement for the previous full text operators.
I will try to explain it briefly with a small example application.
For example this search stage:{
$search: {
index: "fulltextsearch",
facet: {
operator: {
compound: {
filter: [
{
text: {
query: ["00017"],
path: "portfolioIds",
},
},
],
should: [
{
compound: {
must: [
{
autocomplete: {
query: "onplana",
path: "name.DE",
},
},
],
},
},
{
text: {
query: "00000000000onplana",
path: "matnr",
},
},
{
text: {
query: "onplana",
path: "toc",
},
},
],
minimumShouldMatch: 1,
},
},
facets: {
Z_P_SEGMENT: {
type: "string",
path: "attributes_localized.DE.Z_P_SEGMENT.value",
},
Z_P_BAUREIHE_NEU: {
type: "string",
path: "attributes_localized.DE.Z_P_BAUREIHE_NEU.value",
numBuckets: 500,
},
Z_P_PRODUKTKATEGORIE: {
type: "string",
path: "attributes_localized.DE.Z_P_PRODUKTKATEGORIE.value",
numBuckets: 100,
},
},
},
sort: {
"attributes_localized.DE.Z_P_SEGMENT.value_txt":
-1,
},
},
}I have attached a picture of the associated application. A very basic search with three filter and a fulltext search (the autocomplete operator).
I have no idea how to replace the autocomplete operator with the knn operator and this is still a pretty simple exampleMy pains with this limitation are:
- No facets -> All the searches I have built so far include other filters in addition to a full-text search, for which I necessarily need facets
- No possibility to nest the knn operator in a compound -> For example: No possibility to make the knn-Operator optional with should
- No sort -> I love the new atlas search sort operator :(
- My search logic (and I guess other people's too) would have to be refactored, because all previous filters now have to go into the knn operator
Thank you for taking the time
TomTom
shared this idea
·
-
7 votesTom
supported this idea
·
-
6 votesTom
supported this idea
·
-
20 votesTom
supported this idea
·
-
1 voteTom
shared this idea
·
-
9 votesTom
supported this idea
·
-
22 votesTom
supported this idea
·
It would be cool if you could edit both the example document and the search string in the text analysis preview.