-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce WeaviateAsyncClient
as async alternative to WeaviateClient
#1007
Conversation
- Changes base implementation to be purely async using `httpx` and `grpclib`(instead of google's grpc due to [issues](grpc/grpc#25364)) - Uses base implementation in `WeaviateAsyncClient` directly - Subdivides the codebase into `**/asy/*.py` and `**/sy/*.py` directories within each namespace directory - Replace `WeaviateClient` internal calls with event-loop-wrapped blocking calls using the base async implementation - `WeaviateClient` spins up its own personal event loop thread that it schedules async calls to. Should this be a global singleton instead? - `client.batch` is only available on the `WeaviateClient` object, since it is a purely sync algorithm. It depends on the new higher-level event loop thread
Great to see you again! Thanks for the contribution. |
I'm following this as well. I'm looking forward to the async client :) |
…ient into implement-async-client
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we tested enough :)
Hi when is this going to be in the release version |
httpx
andgrpc.aio
WeaviateAsyncClient
directly.pyi
stub fails due to this runtime patchingWeaviateClient
internal calls with event-loop-wrapped blocking calls using the base async implementationclient.batch
is only available on theWeaviateClient
object, since it is a purely sync algorithm. It depends on the new higher-level event loop thread