Hi, I think there is a type mismatch in FT.HYBRID.
Right now FTHybrid / FTHybridWithArgs accepts Vector: VectorFP32, VectorValues, VectorRef
but only VectorFP32 works correctly.
The current implementation in search_commands.go takes vectorExpr.VectorData.Value() and then uses Value()[1] as the vector blob for FT.HYBRID.
That only makes sense for VectorFP32, because:
VectorFP32.Value() => ["FP32", blob]
VectorValues.Value() => ["Values", dim, v1, v2, ...]
VectorRef.Value() => ["ele", name]
So for VectorValues, Value()[1] is just the dimension, not the blob.
And for VectorRef, Value()[1] is just the element name.
The public API kind of says those types are valid, but FT.HYBRID is really only working with raw vector blob input.
This can cause some unexpected problem.
I think this should either:
- validate internally and reject unsupported
Vector types with a clear error
- or use a different input type for
FT.HYBRID instead of reusing the Vector interface from vectorset commands
I lean to option 1 as a safe fix first, because it doesnt break API.
Hi, I think there is a type mismatch in
FT.HYBRID.Right now
FTHybrid/FTHybridWithArgsacceptsVector:VectorFP32,VectorValues,VectorRefbut only
VectorFP32works correctly.The current implementation in
search_commands.gotakesvectorExpr.VectorData.Value()and then usesValue()[1]as the vector blob forFT.HYBRID.That only makes sense for
VectorFP32, because:VectorFP32.Value()=>["FP32", blob]VectorValues.Value()=>["Values", dim, v1, v2, ...]VectorRef.Value()=>["ele", name]So for
VectorValues,Value()[1]is just the dimension, not the blob.And for
VectorRef,Value()[1]is just the element name.The public API kind of says those types are valid, but
FT.HYBRIDis really only working with raw vector blob input.This can cause some unexpected problem.
I think this should either:
Vectortypes with a clear errorFT.HYBRIDinstead of reusing theVectorinterface from vectorset commandsI lean to option 1 as a safe fix first, because it doesnt break API.