groot

目前后台的逻辑是分两种情况处理的： 1. id > 100 这种表达式，后台是把表里所有的id都查看了一遍，找出了 > 100的那些id，所以能够准确知道有多少个被删除。 2. id == xxx 或者 id in [xxx, xxx] 这种表达式，后台为了省掉这个查询的时间，直接通过解析表达式来获得个数，id==xxx直接返回1，id in [xxx, xxx]是直接返回数组里的个数。然后真正的删除操作会异步执行。

The same question is answered here: https://github.com/milvus-io/milvus-sdk-java/issues/273 In the latest code, the submodule milvus-proto is moved to here: https://github.com/milvus-io/milvus-sdk-java/tree/master/sdk-core/src/main To sync the submodule, go to the milvus-sdk-java root path, and...

Java sdk doesn't have connection pool. Each MilvusClient object maintains a long connection. You can use a Map to build your simple connection pool.

The latest version v2.4.3 and v2.3.9 have been supported connection pool, close this issue.

sdk的连接基本上是长连接，proxy如果有多个，那它们的地址都是不同的。客户端连接不同的proxy就应该连接不同的proxy地址。如果只有一个proxy在忙，那说明你的客户端全都连的同一个proxy。milvus本身并没有proxy的balance机制。

The function of `MilvusClient.getCollectionStatistics()` in Java SDK is equal to the `Collection.num_entities` in Milvus Python SDK. This API returns a raw number of entities. It gets the number from Etcd...

getCollectionStatistics() is much faster than query("count(*)") because getCollectionStatistics() quickly picks the number from Etcd but query() requires the collection to be loaded and iterates all the segments to sum up...

https://github.com/milvus-io/milvus-sdk-java/blob/14b9065db1ac5d0d9359a58ddc6e21565cb3a1ec/src/main/java/io/milvus/pool/ClientPool.java#L47 The ClientPool could return null for getClient() method: ``` public T getClient(String key) { try { return clientPool.borrowObject(key); } catch (Exception e) { System.out.println("Failed to get client, exception: "...

Fixed by this pr: https://github.com/milvus-io/milvus-sdk-java/pull/1170/files The exception thrown from GenericKeyedObjectPool is encapsulated by MilvusClientException and thrown out to users.

The fix has been released with v2.4.9 and v2.5.0