You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, our KNN query building contains a significant number of branches depending on the algo, engine and type (radial vs. knn) and with/without model. Any engine specific feature leads to more branching in the KNNQueryBuilder, KNNQuery or KNNWeight
Ideally, we should provide the parsed context to the engine and it should take care of building the query.
That being said, I have seen a convention in OpenSearch where the MappedFieldType can produce the query: See TextFieldMapper for example.
The KNNQueryBuilder would parse the context and then decide if it is radial or knn and then pass it on to the knnVectorFieldType with new methods:
From here, the mapped field type could delegate to the engine to validate and create the given query. This would provide for much better encapsulation and less branching.
Description
Right now, our KNN query building contains a significant number of branches depending on the algo, engine and type (radial vs. knn) and with/without model. Any engine specific feature leads to more branching in the KNNQueryBuilder, KNNQuery or KNNWeight
Ideally, we should provide the parsed context to the engine and it should take care of building the query.
That being said, I have seen a convention in OpenSearch where the MappedFieldType can produce the query: See TextFieldMapper for example.
The KNNQueryBuilder would parse the context and then decide if it is radial or knn and then pass it on to the knnVectorFieldType with new methods:
From here, the mapped field type could delegate to the engine to validate and create the given query. This would provide for much better encapsulation and less branching.
Related Issues
#1914
The text was updated successfully, but these errors were encountered: