groot

@prrs I just discussed with @xiaofan-luan about this pr. He agrees with me that it is not a good design to expose the grpc.ClientInterceptor to sdk users. The input of...

Does the transaction ID generator rely on the interceptCall() of ClientInterceptor? I mean: is the transaction ID generated inside the interceptCall()?

Could you show me an example of how your app achieves "every thread making a grpc call would set its own transaction id" by the interceptCall()?

Ok, I see. traceid is not a const value, it is unique for each thread. Concurrent threads use the same MilvusClient to call rpc interfaces, different threads have different traceid,...

I didn't find a workaround to avoid exposing grpc interceptor, it seems your pr is the only solution to handle the use case. @xiaofan-luan I think I can accept this...

@madogar We still insist that the ClientInteceptor should be hidden inside the ConnectParam. This is our proposal: Hide the constructor of ClientInterceptor inside the ConnectParam, users provide a ThreadLocal object...

close this thread and switch to #955

Sounds like the "truncate" of MySQL. No. Milvus doesn't have such an interface.

The Attu calls `collection.delete(expr="id > xxx")` or `collection.delete(expr="pk != \"\"")` to clean the data. Milvus doesn't provide "cleanCollection" interface or "truncate" interface.

python/javascript这些语言的浮点型是跟系统的位数走的，64位系统就会以64位来表示浮点数，但实际上在调用milvus rpc接口的时候其实都是以float32传输。对于用户来说就像变了个魔术似的。 但java是强制要求Float也就是32位输入，熟悉java的用户不应该有这种迷惑。 以32位浮点输入就已经明确告诉你向量在后台是以32位数据传输，存储，以及计算。所以它根本不可能再变出64位精度的小数给你。 向量近似近邻检索已经是一个模糊检索的概念，用来比对相似的事物。如果说我们要比较两张人脸是否相似，难道我们会去关心这两人的头发数量是否相等么？在大部分场景下，用64位精度的向量就相当于掩耳盗铃，非但对召回率没什么影响，计算负载和内存负载还大了一倍，得不偿失。