Odd behavior when dropping and then subsequently creating a collection #35603
Replies: 1 comment
-
When you call collection.insert(), the data is received by milvus proxy node, and passed to a message queue(in cluster, Pulsar/Kafka is the message queue; in standalone, message queue is an embedded RocksDB). Once the data is stored into the message queue, the insert() API returns. The data is asynchronously consumed by querynode/datanode. This behavior is like a WAL(write-ahead-log) machinery. Only after the data is consumed by querynode, it is visible to search/query requests. So, after the insert() is returned, it doesn't mean the data is visible to search/query requests. Data visibility is controlled by consistency level: https://milvus.io/docs/consistency.md#Consistency-levels When you create a collection, the default consistency level is "Bounded", which means data within a few seconds time window may be invisible.
|
Beta Was this translation helpful? Give feedback.
-
I use milvusdb/milvus:v2.4.5 docker in docker with (pymilvus.version == 2.4.5)
results in
data: ['[]']
where
results in
data: ["[{'id': 451978317871448296, 'distance': 0.9999999403953552, 'entity': {'data': 'hello world'}}]"]
(I get also the same behavior if I first check if it already exists and then drop it, as is shown in the quick-start tutorial)
This feels like it isn't supposed to work like this, what is the proper way to drop a collection and recreating it. Is this intended behavior or might it be a bug?
Beta Was this translation helpful? Give feedback.
All reactions