Is there an existing issue for this?
What would you like to be added?
MilvusClient.query_iterator() has no counterpart on AsyncMilvusClient. Please add AsyncMilvusClient.query_iterator(), returning an async iterator with next() / close() / get_cursor() and matching the sync signature.
Why is this needed?
Async users who need to walk a whole filtered result set currently have to fall back to query(..., limit=N). query has no ordering guarantee, so which N rows come back is undefined — it depends on segment scan order and compaction. The only correct alternative today is hand-rolling primary-key cursor pagination in application code, including the mvcc-timestamp pinning that the sync iterator already does.
Anything else?
A previous attempt (#3483) bundled this with six unrelated changes and was closed before review. That patch also passed the async handler into the sync QueryIterator, whose next() calls handler.query(...) synchronously — it would receive a coroutine instead of rows. A working implementation needs an async driver.
I have a focused patch ready and will open a PR referencing this issue.
Is there an existing issue for this?
What would you like to be added?
MilvusClient.query_iterator()has no counterpart onAsyncMilvusClient. Please addAsyncMilvusClient.query_iterator(), returning an async iterator withnext()/close()/get_cursor()and matching the sync signature.Why is this needed?
Async users who need to walk a whole filtered result set currently have to fall back to
query(..., limit=N).queryhas no ordering guarantee, so which N rows come back is undefined — it depends on segment scan order and compaction. The only correct alternative today is hand-rolling primary-key cursor pagination in application code, including the mvcc-timestamp pinning that the sync iterator already does.Anything else?
A previous attempt (#3483) bundled this with six unrelated changes and was closed before review. That patch also passed the async handler into the sync
QueryIterator, whosenext()callshandler.query(...)synchronously — it would receive a coroutine instead of rows. A working implementation needs an async driver.I have a focused patch ready and will open a PR referencing this issue.